Subscription-based services using industrial blockchains

ABSTRACT

Blockchain-enabled industrial devices and associated systems are configured to support the use of industrial blockchains in connection with product and machine tracking, subscription-based industrial services, device lifecycle management, and other functions. Collections of industrial devices can collectively serve as an industrial blockchain system, with multiple such systems within a supply chain yielding an industrial blockchain ecosystem. This architecture can create distributed, decentralized, tamper-proof records of manufacturing statistics for a product, a product&#39;s history within the larger supply chain, industrial asset usage histories that can be leveraged in connection with lifecycle management, machine usage history for use in connection with subscription-based machine operation, and other such information. The blockchain-enabled industrial devices can be configured to generate multiple versions of a product or machine&#39;s blockchain having respective different access permissions, allowing public and private industrial data to be segregated between public and private industrial blockchains.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/110,031, filed on Aug. 23, 2018, and entitled, “SUBSCRIPTION-BASEDSERVICES USING INDUSTRIAL BLOCKCHAINS,” which claims priority to U.S.Provisional Application Ser. No. 62/665,864, filed on May 2, 2018,entitled “INDUSTRIAL BLOCKCHAINS FOR MANAGEMENT, USE, AND CONTROL OFMANUFACTURING AND SUPPLY CHAIN INFORMATION.” The entireties of theserelated applications are incorporated herein by reference.

BACKGROUND

The subject matter disclosed herein relates generally to industrialautomation systems, and, more particularly, to storage, management, anddistribution of manufacturing and supply chain data

BRIEF DESCRIPTION

The following presents a simplified summary in order to provide a basicunderstanding of some aspects described herein. This summary is not anextensive overview nor is intended to identify key/critical elements orto delineate the scope of the various aspects described herein. Its solepurpose is to present some concepts in a simplified form as a prelude tothe more detailed description that is presented later.

In one or more embodiments, an industrial device is provided, comprisingan execution engine configured to execute a blockchain instruction thatdefines a control event to be processed as a transaction of anindustrial blockchain; and a blockchain engine configured to exchangedata with other devices on an industrial blockchain system, wherein theblockchain engine is further configured to, in response to detection ofa capture trigger, verify an authenticity of the control event, create ablock of the industrial blockchain that records the control event inresponse to verifying the authenticity, and send the industrialblockchain to another device on the industrial blockchain network.

Also, one or more embodiments provide a method for generating a recordof industrial information, comprising executing, by an industrial devicecomprising a processor, a blockchain instruction that specifies acontrol event to be processed as a transaction of an industrialblockchain; in response to detecting occurrence of the control event,verifying, by the industrial device, an authenticity of the controlevent; and in response to the verifying, creating, by the industrialdevice, a block of the industrial blockchain that records the controlevent, and sending, by the industrial device, the industrial blockchainto another device on an industrial blockchain network in which theindustrial device participates.

Also, according to one or more embodiments, a non-transitorycomputer-readable medium is provided having stored thereon instructionsthat, in response to execution, cause an industrial device comprising aprocessor to perform operations, the operations comprising, executing ablockchain instruction that defines a control event to be processed as atransaction of an industrial blockchain; in response to detectingoccurrence of the control event, verifying an authenticity of thecontrol event; and in response to the verifying, creating a block of theindustrial blockchain that records the control event, and sending theindustrial blockchain to another device on an industrial blockchainnetwork in which the industrial device participates.

To the accomplishment of the foregoing and related ends, certainillustrative aspects are described herein in connection with thefollowing description and the annexed drawings. These aspects areindicative of various ways which can be practiced, all of which areintended to be covered herein. Other advantages and novel features maybecome apparent from the following detailed description when consideredin conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example industrial control environment.

FIG. 2 is a generalized high-level diagram illustrating the relationshipbetween blockchain technology and applications that can leverageblockchains.

FIG. 3 is a graphic illustrating a centralized model for accessing andmodifying data.

FIG. 4 is a graphic illustrating a decentralized model for accessing andmodifying data.

FIG. 5 is a graphic illustrating an example blockchain architecture.

FIG. 6 is a diagram illustrating a general architecture of a blockchain.

FIG. 7 is a diagram illustrating a generalized architecture of anexample blockchain platform.

FIG. 8 is a generalized diagram illustrating creation of blocks andvalidation of blocks via consensus-based validation.

FIG. 9 is a generalized diagram illustrating implementation of smartcontracts within a blockchain-driven system.

FIG. 10 is a high-level overview of entities and enterprises within anindustrial supply and distribution chain within whichindustrial-specific blockchains can be utilized.

FIG. 11 is a block diagram of an example blockchain-enabled industrialdevice.

FIG. 12 is a diagram illustrating configuration of an exampleblockchain-enabled industrial controller.

FIG. 13 is a diagram illustrating operation of an exampleblockchain-enabled industrial controller during runtime.

FIG. 14 is a diagram illustrating example inputs to the industrialblockchain engine and example outputs generated by the blockchainengine.

FIG. 15 is a diagram of example blockchain-enabled industrial controllerin which hardware and processing resources for carrying out industrialblockchain functions are segregated from processing resources that carryout the controller's primary control functionality.

FIG. 16 is a diagram of an example ledger entry that can be added to anindustrial device's ledger by a proof engine component.

FIG. 17 is a diagram of an example industrial blockchain networkarchitecture.

FIG. 18 is a diagram of an example blockchain-enabled industrialcontroller illustrating generation of public and private blockchains.

FIG. 19 is a diagram illustrating segregation of private and publicblockchain information in an example industrial blockchain ecosystem.

FIG. 20 is a diagram illustrating generation of blockchain data within aplant intranet.

FIG. 21 is a diagram illustrating an example, high-level architecturefor accessing blockchain information for a manufactured product using amobile user interface application installed on a mobile device.

FIG. 22 is a flowchart of an example methodology for aggregatingindustrial blockchains in connection with manufacture of a compositeproduct.

FIG. 23 is a flowchart of an example methodology for generatingindustrial blockchains having multiple levels of access permission.

FIG. 24 is an example computing environment.

FIG. 25 is an example networking environment.

DETAILED DESCRIPTION

The subject disclosure is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding thereof. It may be evident, however, that the subjectdisclosure can be practiced without these specific details. In otherinstances, well-known structures and devices are shown in block diagramform in order to facilitate a description thereof.

As used in this application, the terms “component,” “system,”“platform,” “layer,” “controller,” “terminal,” “station,” “node,”“interface” are intended to refer to a computer-related entity or anentity related to, or that is part of, an operational apparatus with oneor more specific functionalities, wherein such entities can be eitherhardware, a combination of hardware and software, software, or softwarein execution. For example, a component can be, but is not limited tobeing, a process running on a processor, a processor, a hard disk drive,multiple storage drives (of optical or magnetic storage medium)including affixed (e.g., screwed or bolted) or removable affixedsolid-state storage drives; an object; an executable; a thread ofexecution; a computer-executable program, and/or a computer. By way ofillustration, both an application running on a server and the server canbe a component. One or more components can reside within a processand/or thread of execution, and a component can be localized on onecomputer and/or distributed between two or more computers. Also,components as described herein can execute from various computerreadable storage media having various data structures stored thereon.The components may communicate via local and/or remote processes such asin accordance with a signal having one or more data packets (e.g., datafrom one component interacting with another component in a local system,distributed system, and/or across a network such as the Internet withother systems via the signal). As another example, a component can be anapparatus with specific functionality provided by mechanical partsoperated by electric or electronic circuitry which is operated by asoftware or a firmware application executed by a processor, wherein theprocessor can be internal or external to the apparatus and executes atleast a part of the software or firmware application. As yet anotherexample, a component can be an apparatus that provides specificfunctionality through electronic components without mechanical parts,the electronic components can include a processor therein to executesoftware or firmware that provides at least in part the functionality ofthe electronic components. As further yet another example, interface(s)can include input/output (I/O) components as well as associatedprocessor, application, or Application Programming Interface (API)components. While the foregoing examples are directed to aspects of acomponent, the exemplified aspects or features also apply to a system,platform, interface, layer, controller, terminal, and the like.

As used herein, the terms “to infer” and “inference” refer generally tothe process of reasoning about or inferring states of the system,environment, and/or user from a set of observations as captured viaevents and/or data. Inference can be employed to identify a specificcontext or action, or can generate a probability distribution overstates, for example. The inference can be probabilistic—that is, thecomputation of a probability distribution over states of interest basedon a consideration of data and events. Inference can also refer totechniques employed for composing higher-level events from a set ofevents and/or data. Such inference results in the construction of newevents or actions from a set of observed events and/or stored eventdata, whether or not the events are correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom the context, the phrase “X employs A or B” is intended to mean anyof the natural inclusive permutations. That is, the phrase “X employs Aor B” is satisfied by any of the following instances: X employs A; Xemploys B; or X employs both A and B. In addition, the articles “a” and“an” as used in this application and the appended claims shouldgenerally be construed to mean “one or more” unless specified otherwiseor clear from the context to be directed to a singular form.

Furthermore, the term “set” as employed herein excludes the empty set;e.g., the set with no elements therein. Thus, a “set” in the subjectdisclosure includes one or more elements or entities. As anillustration, a set of controllers includes one or more controllers; aset of data resources includes one or more data resources; etc.Likewise, the term “group” as utilized herein refers to a collection ofone or more entities; e.g., a group of nodes refers to one or morenodes.

Various aspects or features will be presented in terms of systems thatmay include a number of devices, components, modules, and the like. Itis to be understood and appreciated that the various systems may includeadditional devices, components, modules, etc. and/or may not include allof the devices, components, modules etc. discussed in connection withthe figures. A combination of these approaches also can be used.

Industrial controllers and their associated I/O devices are central tothe operation of modern automation systems. These controllers interactwith field devices on the plant floor to control automated processesrelating to such objectives as product manufacture, material handling,batch processing, supervisory control, and other such applications.Industrial controllers store and execute user-defined control programsto effect decision-making in connection with the controlled process.Such programs can include, but are not limited to, ladder logic,sequential function charts, function block diagrams, structured text, orother such platforms.

FIG. 1 is a block diagram of an example industrial control environment100. In this example, a number of industrial controllers 118 aredeployed throughout an industrial plant environment to monitor andcontrol respective industrial systems or processes relating to productmanufacture, machining, motion control, batch processing, materialhandling, or other such industrial functions. Industrial controllers 118typically execute respective control programs to facilitate monitoringand control of industrial devices 120 making up the controlledindustrial assets or systems (e.g., industrial machines). One or moreindustrial controllers 118 may also comprise a soft controller executedon a personal computer or other hardware platform, or on a cloudplatform. Some hybrid devices may also combine controller functionalitywith other functions (e.g., visualization). The control programsexecuted by industrial controllers 118 can comprise any conceivable typeof code used to process input signals read from the industrial devices120 and to control output signals generated by the industrialcontrollers, including but not limited to ladder logic, sequentialfunction charts, function block diagrams, or structured text. Theseprograms can be developed and downloaded to the controllers 118 using asuitable client device 124 executing a controller configurationapplication.

Industrial devices 120 may include both input devices that generate datarelating to the controlled industrial systems to the industrialcontrollers 118, and output devices that respond to control signalsgenerated by the industrial controllers 118 to control aspects of theindustrial systems. Example input devices can include, but are notlimited to, telemetry devices (e.g., temperature sensors, flow meters,level sensors, pressure sensors, etc.), manual operator control devices(e.g., push buttons, selector switches, etc.), safety monitoring devices(e.g., safety mats, safety pull cords, light curtains, etc.), and othersuch devices. Output devices may include motor drives, pneumaticactuators, signaling devices, robot control inputs, valves, and thelike.

Industrial controllers 118 may communicatively interface with industrialdevices 120 over hardwired or networked connections. For example,industrial controllers 118 can be equipped with native hardwired inputsand outputs that communicate with the industrial devices 120 to effectcontrol of the devices. The native controller I/O can include digitalI/O that transmits and receives discrete voltage signals to and from thefield devices, or analog I/O that transmits and receives analog voltageor current signals to and from the devices. The controller I/O cancommunicate with a controller's processor over a backplane such that thedigital and analog signals can be read into and controlled by thecontrol programs. Industrial controllers 118 can also communicate withindustrial devices 120 over a network using, for example, acommunication module or an integrated networking port. Exemplarynetworks can include the Internet, intranets, Ethernet, DeviceNet,ControlNet, Data Highway and Data Highway Plus (DH/DH+), Remote I/O,Fieldbus, Modbus, Profibus, wireless networks, serial protocols, and thelike. The industrial controllers 118 can also store persisted datavalues that can be referenced by the control program and used forcontrol decisions, including but not limited to measured or calculatedvalues representing operational states of a controlled machine orprocess (e.g., tank levels, positions, alarms, etc.) or captured timeseries data that is collected during operation of the automation system(e.g., status information for multiple points in time, diagnosticoccurrences, etc.). Similarly, some intelligent devices—including butnot limited to motor drives, instruments, or condition monitoringmodules—may store data values that are used for control and/or tovisualize states of operation. Such devices may also capture time-seriesdata or events on a log for later retrieval and viewing.

Industrial automation systems often include one or more human-machineinterfaces (HMIs) 114 that allow plant personnel to view telemetry andstatus data associated with the automation systems, and to control someaspects of system operation. HMIs 114 may communicate with one or moreof the industrial controllers 118 over a plant network 116, and exchangedata with the industrial controllers to facilitate visualization ofinformation relating to the controlled industrial processes on one ormore pre-developed operator interface screens. HMIs 114 can also beconfigured to allow operators to submit data to specified data tags ormemory addresses of the industrial controllers 118, thereby providing ameans for operators to issue commands to the controlled systems (e.g.,cycle start commands, device actuation commands, etc.), to modifysetpoint values, etc. HMIs 114 can generate one or more display screensthrough which the operator interacts with the industrial controllers118, and thereby with the controlled processes and/or systems. Exampledisplay screens can visualize present states of industrial systems ortheir associated devices using graphical representations of theprocesses that display metered or calculated values, employ color orposition animations based on state, render alarm notifications, oremploy other such techniques for presenting relevant data to theoperator. Data presented in this manner is read from industrialcontrollers 118 by HMIs 114 and presented on one or more of the displayscreens according to display formats chosen by the HMI developer. HMIsmay comprise fixed location or mobile devices with either user-installedor pre-installed operating systems, and either user-installed orpre-installed graphical application software.

Some industrial environments may also include other systems or devicesrelating to specific aspects of the controlled industrial systems. Thesemay include, for example, a data historian 110 that aggregates andstores production information collected from the industrial controllers118 or other data sources, enterprise resource planning (ERP) and/ormanufacturing execution (MES) systems 104, work order management systems106, or electronic device documentation stores containing electronicdocumentation for the various industrial devices making up thecontrolled industrial systems, repositories for machine or processdrawings and documentation, vendor product documentation storage, vendorknowledgebases, internal knowledgebases, work scheduling applications,or other such systems, some or all of which may reside on an officenetwork 108 of the industrial environment.

The industrial assets that make up a given facility—including industrialcontrollers 118, their associated industrial devices 120, HMIs 114,peripheral systems such as ERP systems, etc.—can generate large amountsof data during plant operation. Much of this information is tracked andrecorded by various means in order to document the various manufacturingprocesses carried out by the assets. For example, data historians, datawarehouses, or MES systems are often used to collect and archivemanufacturing data generated by the industrial assets. This archiveddata can be leveraged to track production statistics, equipment healthstatistics, asset lifecycle management, inventory, key performanceindicators (KPIs), power consumption, or other such factors.

The supply, manufacturing, and distribution chain for a manufacturedproduct extends well beyond the boundaries of a single industrialfacility, and crosses boundaries between several interconnected butsubstantially independent entities. For example, an industrialenterprise (which may comprise one or more manufacturing and warehousefacilities under a common ownership) may receive materials or componentparts from one or more supplier entities that produce the materials orparts. The enterprise may also purchase industrial assets (e.g.,custom-built machines, motor control cabinets, etc.) from one or moreoriginal equipment manufacturers (OEMs). Manufactured products are soldand distributed via retail outlets that may be owned and operated byentities who are independent from the industrial enterprise. While theseindependent entities may collect and track data generated within theirown boundaries, as participants in a common supply chain these variousentities may benefit from selective sharing of their collected data.Reliable and trusted sharing of data can be particularly crucial ifbusiness contracts between the entities are in place, since this sharedinformation can ensure that the terms of the contracts are beingsatisfied. However, since each entity's data is typically collected andstored locally (or on protected remote storage, such as a proprietarycloud-based storage platform), shared data owned by one of the entitiesmay not be easily and readily accessible by third parties, andtrustworthiness of the shared data may be a concern.

Moreover, even within the confines of a single industrial enterprise,information may be collected and tracked using separate (and possiblydisparate) systems, and under different data formats, for differentproduction areas or departments. Aggregating this segregated data into acommon presentation that yields greater insight into manufacturing orbusiness operations can be difficult, requiring normalization of thedisparate information, time synchronization between the items of data,etc.

To address these and other issues, one or more embodiments describedherein relate to the use of blockchain platforms within an industrialfacility as well as throughout a supply, manufacturing, and distributionchain. In one or more embodiments, industrial devices such as industrialcontrollers (e.g., PLCs or other types of automation controllers), motordrives, HMI terminals, telemetry devices, and other such devices areconfigured to support a number of industrial blockchain functions.Collections of these blockchain-enabled industrial devices can benetworked to form an industrial blockchain system in which thecollection of devices capture manufacturing events as transactions,which are verified using consensus-based techniques and added to anindustrial blockchain associated with the product being manufactured.This creates a tamper-proof record of relevant manufacturing statisticsfor the product.

Blockchain-enabled industrial devices can create multiple versions ofsuch industrial blockchains associated with respective different levelsof access permissions, including public blockchains that allow allparticipants within an industrial blockchain ecosystem to viewinformation relating to the product as well as private or semi-publicblockchains that can only be shared with selected members of theindustrial blockchain ecosystem. This can allow information regarding amanufactured product to be reliably recorded in a distributed,decentralized, tamper-proof ledger that maintains both privateinformation for exclusive use within a plant facility as well as publicor semi-public information regarding the product's path through thelarger supply chain. In another example implementation, industrialblockchains and associated smart contracts can be used to track machineusage and operating statistics in connection with subscription-basedmachine operation or maintenance management. Other example systems thatleverage industrial blockchains will also be described herein.

A general, high-level overview of blockchain technology is provided as aprecursor to discussing the industrial-specific applications ofblockchain technology discussed herein. FIG. 2 is a generalizedhigh-level diagram illustrating the relationship between blockchaintechnology and applications 202 that can leverage blockchains. Ingeneral, blockchain is a foundational technology upon which applicationscan be built to leverage the technology. Digital currency such asBitcoin is an example application that uses a public blockchain to actas a distributed ledger in a peer-to-peer network. Blockchain technologyis also used to implement smart contracts, which allow a set ofcontractual rules to be programmed and enforced by a network ofpeer-to-peer devices without requiring a third-party mediator or broker.As will be discussed in more detail herein, one or more embodiments ofthe present disclosure can include industrial devices and applicationsthat leverage blockchain technology to perform supply chain tracking,verify product compliance, perform identity management, monitor andrecord information relating to local manufacturing operations within asingle facility (e.g., within the bounds of the plant's intranet), orother such industrial functions.

Blockchain-based platforms can provide access to data from multipleparties in a decentralized manner, in contrast to platforms that sharedata using a centralized model. FIG. 3 is a graphic illustrating acentralized model for accessing and modifying data. According to thiscentralized model, there is a single “golden copy” 302 of the data beingviewed and acted upon by one or more entities 304 (e.g., systems runningapplications that leverage the data represented by the golden copy 302,client devices operated by respective users, etc.). Any of the entities304 can copy data maintained on the golden copy 302 as a whole or inpart. This golden copy 302 of the data model is updated by commandingstate changes to the model (an example technique for communicating statechanges of objects between components is described in U.S. Pat. No.9,864,365, which is incorporated herein by reference). These statechange instructions are referred to herein as “actions” 306. Copies andviews of the golden copy 302 remain synchronized by observing changes tothe golden copy 302 of the model. These observed changes are referred toherein as “reactions” 308. Table 314 represents a set of actionsperformed on the data and corresponding observed reactions accumulatedas a result of the actions. The collection of actions 306 and reactions308 can be viewed as a set of changes or deltas 310 ordered by time, asrepresented by table 312. This set of deltas 310 can be “played back” byany number of entities to obtain the same consistent data model, withthe golden copy 302 being the model that is trusted by everyone.

By contrast, blockchain-driven platforms decentralize the data model,eliminating the need to maintain a golden copy 302 or distributing themultiple coordinated versions of the truth. FIG. 4 is a graphicillustrating a decentralized model. In a decentralized model, allentities 406 that interact with the data have a copy of the data, andall entities work to keep the data model's transactions ordered andconsistent. Blocks 404 of changes to the data are recorded as atransaction. A distributed ledger 402 of all these changes is maintainedby all entities 406 (or nodes) that participate in the platform. If allentities 406 apply the changes to their own copy of the data then thecopies remain consistent across the entities 406 without the need for asingle golden copy. Each entity maintains a copy of the ledger 402,which represents a continuous chain of transaction blocks 404, hence theterm “blockchain.” When a transaction is performed on the data by one ofthe entities 406, all entities 406 process the transaction and make adetermination regarding the validity of the transaction. If a consensusamong the entities 406 is reached regarding the transaction's validity,each entity updates its copy of the ledger 402 accordingly.

A blockchain consists of a data structure that orders blocks and linksthe blocks cryptographically, thereby acting as an immutable,verifiable, distributed ledger. Blockchains require no centralauthority; instead, trust is established and enforced cryptographically,with participating nodes (e.g., devices associated with entities 406)acting as a consortium and voting on the validity of a block using aconsensus mechanism to manage the distributed ledger. FIG. 5 is agraphic illustrating a blockchain architecture. Blockchains are a linkedhierarchical list 502 of transaction blocks 404, where chains ofrelated, linked transaction blocks 404 within the hierarchy (e.g., chain504) stem from an initial genesis block 506. Each block 404 has acryptographic identity, which is calculated by the header data 508 inthe block. Each block 404 contains the hash of the previous block in thechain.

FIG. 6 is a diagram illustrating a general architecture of an exampleblockchain. Data 610 associated with the block's transactions is hashed,and the collection of transaction data 610 and their associated hashes608 create a Merkle tree 606 of hashes 608 (only two items of data 610are shown in FIG. 6 for clarity; however, a block 404 may be associatedwith more than two transactions). In the illustrated example, each dataitem 610 a and 610 b is hashed to yield two corresponding hash values608 a and 608 b. These two hashes 608 a and 608 b are combined intoanother hash value 602 at the next higher level in the Merkle treehierarchy. Hash values at a given level of the Merkle tree may becombined with other hash values on that level to yield hash values atthe next higher level until the top of the Merkle tree hierarchy isreached.

The Merkle tree 606 is stored separately from the block 404, and onlythe root fingerprint 612 (the top hash) is stored in the block 404. Eachblock 404 also contains a hash 604 of the content of the immediatelypreceding block in the chain. For each block 404, the Merkle tree ofhashes 608 and the hash 604 of the previous block in the chain are usedto create the hash 602 for the block. The data 610 is stored in theMerkle tree 606 separately from the block 404, with the root fingerprint612 being the only part of the Merkle tree 606 stored in the block 404.This nesting of cryptographic hash values yields a digital fingerprintthat renders unauthorized tampering difficult. Compounded with thechaining of transaction blocks 404, the blockchain becomes increasinglydifficult to hack, producing a level of trustworthiness that increasesover time. Improperly modifying a block 404 would require tampering withthe entire transaction history, rendering tampering nearly impossible.In this way, a verifiable, tamper-proof ledger of transactions can beefficiently maintained.

FIG. 7 is a diagram illustrating a generalized architecture of ablockchain platform. The core blockchain functionality 702 (theblockchain creation and management features described above) isimplemented on a network 704 of participating devices or nodes (e.g.,entities 406). The core blockchain ledger is distributed throughout thenetwork, and is independently validated by network members. In a publicmodel, the network 704 is purely peer-to-peer with no central trustauthority. Instead of a central trust authority, network peers areresponsible for validation and decentralized consensus for acceptance ofnew transactions (that is, new blocks 404 representing new transactions)into the blockchain. Public blockchains are secured by the amount ofwork required to create a new block 404. This proof-of-work model canprevent network peers from improperly hijacking or tampering with theblockchain. Private blockchain models—including blockchain applicationsused within an industrial facility as will be described herein—canemploy a central authority to manage the ledger, user identities, andcreation of new blocks.

Applications 706 that employ blockchains are constructed on top of thenetwork layer, which exposes the core blockchain functions. Participantsin the network 704 (the peer devices) are uniquely identified withdigital signatures granted by the network. Participant identities may beanonymous depending on the type of blockchain network model (e.g.,public or private). In all cases, transactions are published, visible,and verifiable on the blockchain.

FIG. 8 is a generalized diagram illustrating creation of blocks andvalidation of blocks via consensus-based validation. Single transactions804 performed by entities 406 (participants in the blockchain network)are gathered into blocks 806 by programmatic components executing on theentities 406 referred to as “miners” 802. Miners 802 possess the entireMerkle tree for the gathered transactions and compete to build a validblock out of the Merkle tree. The first miner 802 to create a block isrewarded. The block is then validated by the other entities 406 based onthe hashes. If valid, the block is added to the blockchain 808.

Since these blocks 806 are created and validated in parallel, differentversions of the truth can be generated. In these cases, the peers(entities 406) vote on which block should be used. Regardless of thefinal set of blocks, all choices are most likely valid. The participantsin the blockchain network can validate transactions and reject invalidor nefarious transactions 810 (e.g., spending the same money twice inthe case of digital currency applications). The system is ultimatelyconsistent and valid.

Some blockchain platforms are also capable of implementing and enforcingsmart contracts, which define rules or agreements between participantsin the blockchain network. FIG. 9 is a generalized diagram illustratingimplementation of smart contracts within a blockchain-driven system. Ingeneral, smart contracts are sets of logic 902 that execute on theblockchain and generate new types of transactions in accordance withrules defined by the logic. The smart contract logic 902 is executed bythe participants of the blockchain. When a smart contract transaction904 is generated, the logic 902 executes on the transaction 904 and maycreate several new transactions 906 designed to satisfy the contract. Onthe Ethereum platform, units of processing “fees” must be provided by aninitiator of a smart contract transaction in order to execute thetransaction. On the Ethereum platform, these fees are referred to asEther or “gas.” The amount of gas required to execute a transaction isgenerally proportional to the amount of work required to execute thetransaction. The more complex the transaction, the more gas must bespent to execute the transaction. These processing “fees” can be used toprioritize transactions based on relative values of the transactions,and can also protect against Denial of Service attacks (e.g., attacksthat place the contract's logic in an infinite loop). Work on selectedtransactions can be prioritized by assigning extra gas to thetransactions.

Various embodiments described herein leverage aspects of blockchainplatforms within the context of industrial facilities, industrialenterprises, and manufacturing and distribution supply chains. To thisend, industrial devices such as industrial controllers, motor drives,data historians, telemetry devices, HMIs, and other such industrialdevices are configured to support creation, validation, and sharing ofblockchains. FIG. 10 is a high-level overview of entities andenterprises within an industrial supply and distribution chain withinwhich industrial-specific blockchains can be utilized. In general,blockchain-enabled industrial devices can utilize blockchain technologyin connection with such tasks as asset and product lifecycle managementwithin a factory 1002; device, machine, line, or factory configurationintegrity tracking; regulatory compliance verification; auditing of lockout/tag out safety procedures within the factory 1002; customer/partnerentitlements management, management and tracking of supply chains 1004across enterprise boundaries; inventory management across a supplychain; contracts management; tracking of manufactured products acrossenterprises of a supply chain or within a factory 1002; or otherapplications to be discussed herein.

The use of blockchains between industrial enterprises can also open thepossibility of subscription-based serves between OEMs 1006 and owners offactories 1002, or between a manufacturing entity and its customers.Blockchains can also be used to track manufactured products to the endconsumers 1008, and public blockchain data generated by a product'straversal through the manufacturing and supply chain can be accessed byconsumers 1008 to obtain information about their purchased products. Adevice vendor 1010 can manufacture and provide blockchain-enabledindustrial devices that are used within industrial factories 1002, OEMfacilities 1006, and other enterprises to facilitate blockchain-drivenindustrial applications. The device vendor 1010 can also act as a trustauthority for blockchain-driven systems that are implemented by theblockchain-enabled industrial devices. Robust identity management fororganizations, people, and products that participate in an industrialblockchain system can ensure the trustworthiness of the participants andthe blockchain data. Both public and private blockchain models can beimplemented depending on the needs of the industrial application usingthe platform.

FIG. 11 is a block diagram of an example blockchain-enabled industrialdevice 1102 according to one or more embodiments of this disclosure.Aspects of the systems, apparatuses, or processes explained in thisdisclosure can constitute machine-executable components embodied withinmachine(s), e.g., embodied in one or more computer-readable mediums (ormedia) associated with one or more machines. Such components, whenexecuted by one or more machines, e.g., computer(s), computingdevice(s), automation device(s), virtual machine(s), etc., can cause themachine(s) to perform the operations described. In some embodiments, oneor more of the machine-executable components can also be embodied onsilicon chips or other microprocessing platforms.

Blockchain-enabled industrial device 1102 can comprise substantially anytype of data-generating industrial device, including but not limited toan industrial controller, a motor drive, an HMI terminal, a visionsystem, an industrial optical scanner, a meter, a telemetry device, anindustrial safety device, a safety relay, a barcode stamper, an ERPserver, an MES server, an industrial Internet of Things (IIoT) device,or other such device or system. Industrial device 1102 can include aproof engine component 1104, a cryptographic component 1106, a hashingcomponent 1108, an instruction execution component 1110, a userinterface component 1112, one or more processors 1116, and memory 1118.In various embodiments, one or more of the proof engine component 1104,a cryptographic component 1106, a hashing component 1108, an instructionexecution component 1110, a user interface component 1112, the one ormore processors 1116, and memory 1118 can be electrically and/orcommunicatively coupled to one another to perform one or more of thefunctions of the blockchain-enabled industrial device 1102. In someembodiments, components 1104, 1106, 1110, and 1112 can comprise softwareinstructions stored on memory 1118 and executed by processor(s) 1116.Blockchain-enabled industrial device 1102 may also interact with otherhardware and/or software components not depicted in FIG. 11. Forexample, processor(s) 1116 may interact with one or more external userinterface devices, such as a keyboard, a mouse, a display monitor, atouchscreen, or other such interface devices.

Proof engine component 1104 can be configured to validate industrial orsupply chain transactions for inclusion in a new block of an industrialblockchain in accordance with a blockchain instruction. Cryptographiccomponent 1106 can be configured to encrypt and decrypt transactiondata, recipe data, or other information exchanged with otherblockchain-enabled industrial devices within a blockchain system orecosystem. In some embodiments, cryptographic component 1106 canleverage private keys 1122 and public keys 1124 in connection withencryption and decryption of blockchain information. Hashing component1108 can be configured to hash transaction data and generate Merkletrees in accordance with a blockchain instruction. Instruction executioncomponent 1110 can be configured to execute industrial blockchaininstructions that create blocks representing transactions received orexecuted by the blockchain-enabled industrial device 1102, add theblocks to industrial blockchains maintained on the device 1102, andupdate the device's blockchain ledger 1126.

User interface component 1112 can be configured to receive user inputand to render output to the user in any suitable format (e.g., visual,audio, tactile, etc.). In some embodiments, user interface component1112 can be configured to communicatively interface with a developmentapplication that executes on a client device (e.g., a laptop computer,tablet computer, smart phone, etc.) that is communicatively connected tothe blockchain-enabled industrial device 1102 (e.g., via a hardwired orwireless connection). The user interface component 1112 can then receiveuser input data and render output data via the development application.In other embodiments, user interface component 1112 can be configured togenerate and serve suitable graphical interface screens to a clientdevice, and exchange data via these graphical interface screens. Inputdata that can be received via user interface component 1112 can include,but is not limited to, user-defined control programs or routines thatinclude industrial blockchain instructions, blockchain configurationparameters (which may be provided as configuration parameters of theblockchain instructions), or other such data.

The one or more processors 1116 can perform one or more of the functionsdescribed herein with reference to the systems and/or methods disclosed.Memory 1118 can be a computer-readable storage medium storingcomputer-executable instructions and/or information for performing thefunctions described herein with reference to the systems and/or methodsdisclosed. As will be described in more detail below, processor(s) 1116and memory 1118 may be segregated from the primary memory that performsthe device's real-time control functions. Collectively, components1104-1112 described above (or a subset thereof) can be viewed as ablockchain engine 1128 that supplements an industrial device's nativefunctionality with blockchain-related functionality, as will bedescribed in more detail below.

In various embodiments, industrial devices such as industrialcontrollers, motor drives, HMI terminals, industrial appliances,industrial Internet of Things (IIoT) devices, and other such devices areprovided with integrated blockchain creation, validation, sharing, andmanagement functionalities. In some embodiments, aspects of theseblockchain functions can be configured by the device owner. FIG. 12 is adiagram illustrating configuration of a blockchain-enabled industrialcontroller 1210, which may be a hardware controller, a soft controller,a cloud-based controller or other type of industrial controller.Although the example illustrated in FIG. 12 depicts an industrialcontroller 1210 as the blockchain-enabled device, it is to beappreciated that industrial blockchain functionality is not limited toimplementation on industrial controllers. Blockchain-enabled industrialcontroller 1210 can be configured using a suitable device configurationapplication 1208 (e.g., a ladder logic development application) thatexecutes on a client device 1206 (e.g., a laptop computer, a desktopcomputer, a tablet computer, a human-machine interface terminal, etc.).Using device configuration application 1208, a user can develop anddownload a control program 1204 (e.g., a ladder logic program, asequential function chart program, function block diagrams, structuredtext, etc.) to the controller 1210, as well as configure thecontroller's I/O modules and individual I/O parameters, networkingparameters, and other such configurable features.

Device configuration application 1208 also supports inclusion ofconfigurable blockchain instructions 1202 within the control program1204 for execution by the industrial controller 1210. Each blockchaininstruction 1202 added to the control program 1204 can have anassociated set of instruction parameters 1212 that can be configured bythe user via the device configuration application 1208. Exampleinstruction parameters 1212 for an industrial blockchain instruction1202 can include, but are not limited to, production parameters of amanufactured product for which a blockchain is to be created, priorblockchain information that is expected to be received from otherentities that participate in the blockchain (e.g., other controllers orindustrial devices within the plant, outside entities that participatein a supply or manufacturing chain such as OEMs or part suppliers,etc.), supplier entities that provide materials or components for themanufactured product (if the supplier does not provide its ownblockchain from which this information can be derived), an expirationtime or expiration event for the blockchain defining a time that theblockchain can be deleted (in scenarios in which the blockchain only hasutility for a limited time during production and can therefore betransient rather than persistent), or other such configuration aspects.In general, blockchain instruction 1202, when executed by thecontroller's instruction execution component 1110 (which may be part ofthe controller's program execution component 1306 in some embodiments;see FIG. 13), can create a block representing a number of transactionsreceived or executed by the controller 1210, and add the block to anexisting internal blockchain maintained on the controller 1210 or sendthe block to another node device in the production line or supply chain.

To simplify configuration of industrial devices to manage blockchains,device configuration application 1208 can include a library of codespecific to blockchain creation and management by industrial devices.Such libraries can include sets of blockchain instructions that arespecific to defined industries, verticals, or industrial applications.For example, a Brew software library may include blockchain instructionsspecific to brewery systems. These industry- or application-specificblockchain instructions can set the root of the blockchain based on theselected industry or vertical and auto-generate code for configuring theblockchain in accordance with common standards used within the selectedindustry. Other user-configurable instruction parameters of theseindustry-specific blockchain instructions may allow the developer tospecify parameters of their specific application (e.g., the number ofbrewing vats being used) that may vary across different implementations.

In some embodiments, device configuration application 1208 can allowusers to configure blockchains to be generated by a blockchain-enableddevice 1102 (e.g., controller 1210 or another type of industrial device)using unified modeling language (UML) diagrams or other interfaces forcreating linkages and defining hierarchies. A blockchain editor ofdevice configuration application 1208 can allow the user to definedependency diagrams that include automation objects maintained in theblockchain-enabled industrial device 1102. Each automation objectdefines the data and behavior of its associated device or data object,and can be set to be either public or private via the blockchain editor.The editor can display all available automation objects supported by theindustrial device 1102 and let the user check the objects to be includedin the blockchain. In some embodiments, the blockchain editor can alsoallow dependency diagrams to be drawn to define reliance betweenobjects. Inheritance rules can be leveraged for automation objects toautomatically determine parents. The editor can also allow users todefine whether an automation object is to be traced or untraced, wheresetting an object to be traced makes the object the root of theblockchain, and multiple traced automation objects yield a hierarchy ofdependencies. In this way, industrial automation blockchains can bedefined without requiring complicated programming Device configurationapplication 1208 can also include a template editor that can be used todefine smart contracts to be enforced by the blockchain.

A blockchain tester or simulator can also be used to verify operation ofthe industrial blockchain before deployment. In an example scenario, anOEM may simulate a blockchain associated with their machine beforeshipping the machine to a customer (e.g., a manufacturing entity). Insuch scenarios, the blockchain can be run on the OEM's local network toconfirm that the blocks are generated correctly.

FIG. 13 is a diagram illustrating operation of the blockchain-enabledindustrial controller 1210 during runtime. As noted above, one or moreblockchain-enabling components of controller 1210 (e.g., components1104-1110 described above in connection with FIG. 11) can implement ablockchain engine 1128 on the controller 1210 that supplements thecontroller's native functionality (e.g., execution of industrial controlprograms and associated I/O control in the case of industrialcontrollers) with blockchain-related functionality. In variousembodiments, blockchain engine 1128 can be implemented as aspecial-purpose chip, a firmware module embedded in theblockchain-enabled industrial controller 1210, a component built intothe hardware design, a software module executing in an open operatingsystem, or another implementation.

Blockchain-enabled industrial controller 1210 includes a programexecution component 1306 that executes a control program 1204, which wasdeveloped and installed on the controller 1210 as described above inconnection with FIG. 12. As noted above, control program 1204 caninclude one or more blockchain instructions 1202 that facilitatecreation of transaction blocks and management of industrial blockchainsthat include these blocks.

To facilitate monitoring and control of an industrial machine, system,or process 1320 during runtime, controller 1210 receives input signals1312 from one or more industrial input devices 1316 (e.g., sensors,telemetry devices, etc.) via the controller's analog and/or digital I/O1308, and program execution component 1306 generates analog and/ordigital control outputs 1314 directed to one or more industrial outputdevices 1318 (e.g., actuators, motor drives, contactors, indicatorlights, etc.) based on values of the input signals 1312 and controlsequences defined by the control program 1204. Control outputs 1314 canalso be initiated in response to or based on operator commands 1302received via an HMI 114 or other type of user interface or faceplate(e.g., the user controls of a motor drive). These operator commands 1302can, for example, modify setpoint values or other parameters of thecontrol sequence, initiate or halt control actions, select operatingmodes for the control sequence, or perform other types of manuallyinitiated actions. In general, blockchain-enabled industrial controller1210 is capable of carrying out basic real-time monitoring and controlfunctionality typically associated with industrial controllers.

In addition, blockchain engine 1128 is capable of executing blockchaininstructions 1202 included in the control program 1204 and previouslyconfigured by the controller programmer. For example, blockchaininstruction 1202 can be configured to recognize specific user-definedevents as transactions to be added to a block 1322. Such transactionscan include, for example, detected events or measured metrics observedon the controlled machine, system, or process 1320 based on inputsignals 1312 (e.g., temperature, pressure, or flow metrics; qualitycheck results such as bolt torque or leak test values; etc.), operatoractions identified based on the operator commands 1302 or operatorinteractions with control panel devices or safety devices (e.g.,pushbuttons, switches, light curtains, safety mats, safety pull cords,etc.), programmatic events generated internally by the controller 1210based on execution of control program 1204 (e.g., alarm events,controller diagnostic events, etc.), deviations of measured telemetryvalues from a defined range, detected states of industrial sensors,changes of states of industrial safety devices (e.g., light curtains,emergency stop push buttons, pull cords, safety mats, etc.), or othersuch recordable transactions.

In accordance with the configuration parameters associated with theblockchain instruction 1202, blockchain engine 1128 can assign one ormore industrial transactions to a block 1322 having a format similar tothose described above (see, e.g., FIGS. 5 and 6) and assign the block1322 to a blockchain 1304. The determination as to whether a singletransaction is to be added to a block 1322 or, alternatively, ifmultiple transactions are to be aggregated into a block can depend inpart on the workflow of the manufacturing process or user-definedpreferences. As will be discussed in more detail below, blockchain 1304can be one or both of a public blockchain or a private blockchain. Insome embodiments, the instruction parameters 1212 of the controller'sblockchain instructions 1202 can allow a user to configure whether ablock 1322 is to be added for each individual transaction or whethermultiple transactions are to be bundled into a single block 1322. In thelatter case, the parameters 1212 can also allow the user to define theconditions for bundling transactions into a single block. For example, ablockchain instruction 1202 can be configured that bundles a selectedset of data items or events into a block 1322 upon completion of adefined production cycle corresponding to a single manufactured part orbatch. In this way, each block 1322 can be associated with a set oftransactions and data corresponding to a single part or productioncycle. Other capture triggers or capture criteria that initiatecapturing of a control event and adding a record of the event to a block1322 can also be configured using blockchain instruction 1202. Forexample, blockchain instruction 1202 can be configured to capture one ormore controller values or control event information on a periodic basis,to capture the controller values or control event information inresponse to a defined condition of the control event (e.g., when ameasured performance parameter falls outside a defined range, inresponse to completion of a production cycle, etc.), to capture thecontroller values or control event information in response to a manualrequest to capture control event information received from an HMI oranother device, etc. Blockchain engine 1128 can validate industrialtransactions as well as add data to the blockchain 1304.

FIG. 14 is a diagram illustrating example inputs 1414 to the industrialblockchain engine 1128 and example outputs 1416 generated by theblockchain engine 1128. In general, blockchain engine 1128 allowsindustrial devices and applications (e.g., industrial controller 1210 orother types of blockchain-enabled industrial devices 1102 such as HMIterminals, motor drives, sensor and telemetry devices, IIoT devices, ERPand MES systems, industrial gateway devices, industrial data historians,or other such devices) to participate in a blockchain network comprisingother blockchain-enabled industrial devices as well as non-industrialblockchain entities. In some implementations, the industrial blockchainnetwork can reside entirely within the confines of a manufacturingfacility on the plant's local intranet, such that the distributeddatabase represented by the industrial blockchain is accessedexclusively by authorized plant personnel (e.g., a private blockchain).In other implantations, the blockchain network can comprise multipleentities within a manufacturing, supply, and retail chain, and accesspermissions to the blockchain information can be layered such that thedegree of access is a function of user identity and/or role. In suchimplementations, the blockchain can comprise both public and privatedata, permitting selective access to information maintained in thedistributed, de-centralized database.

In some embodiments, blockchain-enabled industrial devices 1102 can beconfigured to support different types of blockchain instructions thatexecute different blockchain functions. For example, a transactioninstruction 1402 can be used to configure the blockchain engine 1128 togenerate hashes for transaction data in connection with generating a newblock 1322, as well as to perform block validation. The blockchainengine's hashing component 1108 can be configured to hash transactiondata and generate Merkle trees in accordance with the transactioninstruction 1402. Since new blocks leverage the hash of the previousblock in the chain to generate the hash for the new block, blockchainengine 1128 can also receive the previous hash 1406 of the previousblock in the chain. If the previous block comprises transactions thatwere generated by the controller 1210 itself, the previous hash 1406 mayhave been generated by the blockchain engine 1128 itself when theprevious block was generated. In some scenarios, depending on themanufacturing workflow and the architecture of devices that execute themanufacturing process, the previous block of transactions may have beengenerated by another blockchain-enabled industrial device 1102 (e.g.,another blockchain-enabled controller 1210 or another type ofblockchain-enabled industrial device 1102) or by a third-party entity.In such scenarios, the previous hash 1406 may be received by theindustrial controller 1210 from another device or system in theblockchain peer network. This previous hash 1406 together with the datafor a set of transactions to be included in a new block are used togenerate the next hash 1412 for the block. The proof engine component1104 can be configured to validate transactions for inclusion in the newblock in accordance with the transaction instruction 1402. In someembodiments, the proof engine component 1104 can cooperate with aconsortium of other devices on the blockchain system to determine thevalidity of the transactions using consensus-based techniques. Similarto the techniques described above in connection with FIG. 8, proofengine component 1104 can leverage miners—programmatic entities thatbuild blocks based on Merkle tree information for gatheredtransactions—in connection with consortium-based validation of blocks oftransactions.

A block instruction 1404 (e.g., blockchain instruction 1202 in the caseof industrial controllers) can configure the blockchain engine 1128 toperform updates to the controller's ledger 1126 to add one or moretransactions of a new block after the block's transactions have beenvalidated by proof engine component 1104. The proof engine component1104 can also validate transactions generated by other node devices onthe industrial blockchain network in accordance with a consensus-basedvalidation technique, and broadcast its validation findings regardingthe validity of the transactions to other node devices on the blockchainnetwork (e.g., other blockchain-enabled industrial devices 1102). In anexample scenario, proof engine component 1104 can send informationregarding a control event originating on its associatedblockchain-enabled industrial device 1102 to one or more other deviceson the industrial blockchain network for validation. The proof enginecomponent 1104 of the originating device, as well as those of the otherdevices on the blockchain network, can independently validate theauthenticity of the control event using a suitable consensus-basedvalidation technique (e.g., proof-of-work, proof-of-state, practicalbyzantine fault tolerance, etc.). The blockchain engines 1128 sharetheir independently derived conclusions with one another, and will onlyupdate their respective blockchain ledgers 1126 if at least a minimumnumber of the devices report that the control event is authentic.

In some embodiments, blockchain engine 1128 can broadcast validatedtransactions as verified ledger deltas 1408 that can be used by otherdevices on the blockchain network to update their own ledgers 1126.Proof engine component 1104 can also update the device's own copy ofledger 1126 based on verified ledger deltas received from other deviceson the blockchain network to ensure that validated transactionsoriginating elsewhere on the network are recorded in the device's ownledger 1126. Blockchain engine 1128 can also generate and sendinformation regarding errors 1410 discovered in a block of transactions(either a self-generated block or a block received from another deviceon the blockchain network).

In some embodiments, blockchain-enabled industrial devices 1102 may beconfigured such that only nodes (blockchain-enabled industrial devices)affected by a transaction will verify the transaction in order to reduceCPU usage relative to verifying the entire blockchain. In suchembodiments, the proof engine component 1104 of an industrial device1102 may be configured to select whether to perform validation analysison a given block of transactions based on a determination of whether thetransactions of the block are relevant to the device's own monitoringand control operations. In an example implementation, the blockchainengine 1128 can allow a user to specify transaction criteria that theindustrial device 1102 will use as a basis for determining the types oftransactions on which the device will perform validation analysis.Example transaction criteria can include, but are not limited to,identities a subset of other devices in the blockchain system whosetransactions will be validated by the device 1102, identities ofmachines or industrial processes whose transactions will be validated bythe device 1102, or other such criteria. Based on this configurationinformation, the proof engine component 1104 will perform its validationanalysis only on transactions that satisfy the defined criteria. Thisselective merit-based verification of blocks can conserve processingresources on the industrial device 1102 relative to verifying all blocksof a blockchain, while ensuring that all transactions are reliablyverified by at least a subset of industrial devices 1102 to which thetransactions are most relevant.

In some embodiments, blockchain engine 1128 can also include a privatekey 1122 and a public key 1124 that can be used by the controller 1210or other industrial device 1102 to securely share information with otherentities on the blockchain network. As will be discussed in more detailherein, this can include secure sharing of recipe data for execution ona selected industrial controller or at a selected industrial facility.

Each blockchain-enabled industrial device 1102 can include a securestorage area (e.g., memory 1118) that is separate from the storage usedfor real-time monitoring and control. Similarly, processing resourcesused by the blockchain-enabled industrial devices 1102 can be segregatedfrom the primary processing resources that perform real-time monitoringand control (e.g., the processing resources used to execute controlprogram 1204 and update the device's I/O). In this way, execution ofblockchain functionality on the industrial device 1102 does not impactperformance of the device's primary monitoring and control functions. Insome embodiments, this can be achieved using multi-core processing topartition blockchain transactions from real-time control. FIG. 15 is adiagram of example blockchain-enabled industrial controller 1210illustrating that hardware and processing resources for carrying outindustrial blockchain functions are segregated from processing resourcesthat carry out the controller's primary control functionality. In thisexample architecture, control components 1514 can include a memory 1504on which is stored the control program 1204 executed by the controller1210 and the data table 1508 that stores real-time values of thecontroller's digital and analog inputs and outputs, setpoint values,calculated values, or other data tag values. Control components 1514also include one or more I/O modules 1512, which interface thecontroller 1210 with input and output devices (not shown) that make up acontrolled industrial system or process. I/O modules 1512 arecommunicatively connected to the controller's backplane 1516 orcommunication bus, and exchange data with the data table 1508 via thebackplane 1516. I/O modules 1512 can include input modules that measureaspects of the controlled system as digital and/or analog signals (e.g.,4-20 mA signals, 0-10 VDC signals, switched input voltages, etc.) andwrite these values to designated data tags or memory addresses of datatable 1508. I/O modules 1512 can also include output modules that readdigital or analog values from designated data tags or memory addressesof data table 1508 and translate these values into output signals (e.g.,switched outputs, 4-20 mA output signals, 0-10 VDC output signals, etc.)directed to output devices of the controlled system. One or morecontroller processors 1502 or execution engines execute the controlprogram 1204 and control updating of data values in the data table 1508in accordance with measured data from the I/O modules 1512 and executionof the control program 1204.

In this illustrated example, blockchain engine 1128 is embodied as asub-system of controller 1210, and is implemented using separate memoryand processing resources from control components 1514. For example,blockchain engine 1128 can utilize its own processor 1116 and memory1118, which are separate from controller processor(s) 1502 and memory1504. In this way, blockchain functions (e.g., transaction processingand validation, block generation, smart contract processing andenforcement, etc.) performed by the blockchain engine 1128 is segregatedfrom control-related analytics, and is not necessarily implemented usingthe primary control language of the controller 1210. While components ofthe blockchain engine 1128 can read data from and write data to thecontroller's data table 1508 (e.g., via a data bus 1518) in connectionwith performing blockchain creation and management functions, theprocessing resources used to carry out these blockchain functions arephysically separated from those used to carry out control. In this way,blockchain functions carried out by the blockchain engine 1128 do notimpact performance of the controller's basic control functionality. Asnoted above, although FIG. 15 depicts the embedded blockchain engine1128 as being a sub-system of an industrial controller, blockchainengine 1128 can also be embedded on other types of industrial devices,including but not limited to motor drives, industrial sensors, visionsystems, safety relays, barcode stampers, or other such devices.

FIG. 16 is a diagram of an example ledger entry 1602 that can be addedto the industrial device's ledger 1126 by proof engine component 1104according to one or more embodiments. Ledger entry 1602 can represent asingle block of the blockchain, and can be stored as part of ledger 1126in secure memory 1118. The ledger 1126 can be one of multiple copies ofthe ledger distributed among multiple devices or entities thatparticipate in the industrial blockchain network (e.g., multipleblockchain-enabled industrial devices 1102 or other types ofparticipating devices), with each device or entity maintaining its copyof the ledger 1126 based on validated transaction deltas generated bythe device itself or received from other devices on the blockchainnetwork.

Blockchain infrastructure data 1604 can include, but is not limited to,the hash of the previous block in the blockchain (e.g., previous hash604 in FIG. 6), an identifier for the block represented by the ledgerentry 1602 (e.g., index 614 in FIG. 6), timestamps for the transactionsincluded in the block (e.g., timestamp 616 in FIG. 6),repudiation-related data, the Merkle tree root (e.g., root fingerprint612), or other data relating to the blockchain infrastructure. Thepayload 1606 of the ledger entry can include transaction data 1608 aswell as associated metadata 1618, which may be specific to theindustrial applications that are leveraging the blockchain. For example,metadata 1618 can define data boundaries specifying who is permitted toaccess respective subsets of the transaction data 1608. In this regard,selected subsets of the data 1608 may be associated with respective userroles or user identities that are permitted to access and view thosedata subsets. In a related aspect, metadata 1618 can also definepublic/private boundaries for the data 1608. These boundaries canspecify which sets of the data 1608 are to be made publicly accessibleregardless of user roles or identities, and which sets are to be madeprivately accessible only to users within a given plant or industrialenterprise. In some embodiments, the data boundaries and public/privateboundaries can be configured on the device 1102 using deviceconfiguration application 1208 (e.g., as one or more parameters ofblockchain instruction 1202).

Ledger entry 1602 can also include a public key 1610 of the associatedblockchain-enabled industrial device 1102 and one or more private keys1612. These keys can be used to encrypt and decrypt information sharedwith other devices or entities on the blockchain network. In an examplespecific to industrial applications, an entity on the blockchain networkcan provide encrypted recipe data to a blockchain-enabled controller(e.g., controller 1210). The recipe data may be proprietary informationdefining parameters and/or executable instructions for manufacturing aparticular product or batch. The recipe data can be encrypted by thesending entity's private key 1612 and decrypted by the receivingcontroller using the public key 1610 and the controller's own privatekey. Once decrypted, the receiving controller can execute the recipe tofacilitate manufacture of the product. In this example scenario, thereceiving controller can leverage the blockchain information to verifythat the recipe is from a trusted source before executing, and to verifythat the controller itself has been authorized to execute the recipe.Distribution and use of the recipe data can be subject to a smartcontract implemented by the blockchain network, as will be described inmore detail herein.

FIG. 17 is a diagram of an example industrial blockchain networkarchitecture. In this example implementation, an industrial blockchainecosystem 1702 can comprise multiple participating blockchain systems1704. One or more of the participating blockchain systems 1704 can beindustrial systems comprising multiple blockchain-enabled industrialdevices 1102 (e.g., blockchain-enabled controllers 1210, HMI terminals,gateway devices, MES systems, motor drives, meters or other telemetrydevices, sensors, ERP systems, data historians IIoT devices, etc.). Theindustrial blockchain ecosystem 1702 can span multiple geographic,organizational, and business boundaries. The blockchain systems 1704 canbe owned by, or may represent, entities representing differentdisciplines within the manufacturing, supply, distribution, and/orretail chain, including but not limited to engineering and productdevelopment, product manufacturing, product testing, shipping, technicalsupport, business and accounting, etc. Systems 1704 may be associatedwith producers and manufacturers, suppliers, sub-system suppliers (e.g.,OEMs), designers and engineers, retailers, shippers, customers, endconsumers, or other such entities.

In some embodiments, blockchain-enabled industrial devices 1102 can beadded to this infrastructure in a substantially plug-and-play manner.For example, upon power-up, a blockchain-enabled industrial device 1102can broadcast its identity as a blockchain-enabled device to otherdevices on the blockchain network, and can also detect otherblockchain-enabled devices. Devices across all layers of a plant(control, middleware, enterprise, etc.) can share their identities,born-on certificates, firmware versions, and other such information withother peer devices on the blockchain system 1704 (and by extension thelarger blockchain ecosystem 1702). These devices can be preconfigured tocooperate with other blockchain-enabled industrial devices as aconsortium within the blockchain system 1704 to authenticatetransactions using consensus mechanisms (e.g., practical byzantine faulttolerance, proof-of-work, proof-of-state, etc.).

To accommodate brownfield environments that includenon-blockchain-capable devices, blockchain-enabled gateway devices canalso be deployed. These gateway devices can allow legacy devices withoutintegrated blockchain capability to proxy into the blockchaininfrastructure. The gateway devices can create and link blocks of ablockchain based on data generated by the legacy devices and monitoredby the gateway device via the network. In an example hybridarchitecture, blocks can be created in an industrial controller whilethe blockchains that record transactions on the controller can residewithin the gateway device. In another example architecture, an MESsystem can perform the blockchain creation and management functions formultiple monitored devices and systems within the plant. These proxysystems can synchronize blockchains from different sources, certifywhich chains are trusted, and perform other such blockchain managementfunctions.

Since manufacturing and distribution chains can comprise multipledifferent entities having complex business interrelationships, eachentity may wish to regulate access to the information shared with otherentities within the chain. For example, a supplier entity thatmanufactures and provides parts used by another manufacturing entity formanufacture of its own products may wish to provide only a limitedsubset of its available blockchain data relating to manufacture of thepart (e.g., results of quality tests, manufacturing time stamps, asource of materials used to manufacture the part, etc.), whilewithholding other proprietary manufacturing statistics generated duringproduction of the part and recorded in a blockchain. Accordingly,blockchain-enabled industrial devices 1102 can be configured to generatemultiple versions of a blockchain with different degrees of accesspermissions. FIG. 18 is a diagram of an example blockchain-enabledindustrial controller 1210 illustrating generation of public and privateblockchains. During runtime, one or more embodiments ofblockchain-enabled industrial controller 1210 (or otherblockchain-enabled industrial devices 1102) can be configured to createmultiple versions of a blockchain to facilitate layered access tomanufacturing data generated by the blockchain system within which thecontroller 1210 operates. This can include creating a public blockchain1304 a and a private blockchain 1304 b, each of which comprises datathat respective different sets of users or systems within the blockchainecosystem 1702 are allowed to access. For example, the public blockchain1304 a may include publicly accessible part count or material sourceinformation that may be accessed by all blockchain systems 1704 withinthe ecosystem 1702, while the private blockchain 1304 b may includeproprietary recipe information that is to be kept private from the othersystems 1704 within the ecosystem.

In some embodiments, users can identify which data items are to beincluded in each version of the blockchain 1304, as well as the scope ofaccess to be assigned to each version of the blockchain 1304, via adevice configuration interface (e.g., device configuration application1208). In an example configuration technique, device configurationapplication 1208 may allow the user to define two or more blockchains towhich transactions are to be added by the blockchain-enabled industrialcontroller 1210, as well as the scope of access to be to be assigned toeach blockchain. The scope of access may be defined, for example, byidentifying the devices, entities, or blockchain systems 1704 that areto be permitted access to the data recorded by each version of theblockchain. Once these various blockchain versions are defined,blockchain instructions 1202 can be added to the industrial controlprogram 1204. The blockchain instructions 1202 can include instructionparameters 1212 that allow the user to select data items or controlevents (e.g., timed events, change-of-state events, alarm events etc.)that are to be considered transactions to be included in a blockchain,as well as a parameter that allows the user to select which of thedefined versions of the blockchain 1304 the transaction is to beassociated with. In another configuration example, a tag dialog can beinvoked on the device configuration application 1208 that allows theuser to select which data tags are to be made public so that otherdevices on the blockchain network can see the path.

FIG. 19 is a diagram illustrating segregation of private and publicblockchain information in an example industrial blockchain ecosystem.The example ecosystem depicted in FIG. 19 comprises a number ofblockchain systems associated with respective entities that participatein a manufacturing and distribution chain, including supplier entities1902, a manufacturing entity 1904, a warehouse entity 1906, and retailentities 1908. Supplier entities 1902 may be manufacturing entities thatprovide parts or materials to manufacturing entity 1904 thatmanufactures a product using the provided parts or materials. One ormore supplier entities 1902 may be OEMs that provide custom-builtmachines to the manufacturing entity 1904. Manufacturing entity 1904 mayprovide finished products to a warehouse 1906, which may be owned by thesame industrial enterprise that owns the manufacturing entity 1904.Warehouse 1906 may distribute product to retail entities 1908. It is tobe appreciated that the example industrial ecosystem depicted in FIG. 19is only intended to be exemplary, and that an industrial blockchainecosystem can comprise any collection of entities of various roles.

One or more of the blockchain systems that make up the ecosystem canmaintain both private blockchains 1304 b for internal use as well aspublic blockchains 1304 a accessible to other participating entities inthe blockchain ecosystem. Public and private industrial blockchains canbe used within a blockchain ecosystem comprising several businessentities of a supply chain for a variety of applications, including butnot limited to tracking of machine performance and usage, tracking ofproducts across a manufacturing facility or within a single industrialenterprise, tracking of products across the larger supply anddistribution chain, distribution of proprietary recipe information, andproduct auditing. These example industrial blockchain applications arediscussed in more detail below.

Blockchain-enabled industrial devices that support generation of publicand private industrial blockchains can be used to track performance andusage of machines sold by OEMs to their customer manufacturing entities.In an example scenario, multiple machines built by different OEMs (e.g.,one or more supplier entities 1902) can be deployed to an end usermanufacturing site (manufacturing entity 1904). According to avertical-specific example, manufacturing entity 1904 may be a beveragefactory that runs a bottling line comprising fillers, sealers,conveyors, cartoners, and other machines. Some of the machines that makeup the bottling line may be built and provided by one or more OEMs.During the machine build, blockchain-enabled industrial devices 1102 atthe OEMs can generate private blockchains 1304 b that recordtransactions and associated data associated with the machine buildingprocess that are to be accessible only by authorized devices andpersonnel associated with the OEM.

The OEM's blockchain-enabled industrial devices 1102 can also beconfigured to generate public blockchains 1304 a that record publiclyshared transaction data that can be accessed and viewed by other devicesthat participate in the blockchain ecosystem, including devicesassociated with the customer manufacturing entity 1904. This publiclyaccessible information can include, for example, results of factoryacceptance tests (FATs) performed on the machine prior to shipping tothe customer. Blockchain-enabled industrial devices that make up themachine, as well as blockchain-enabled test equipment used by the OEM,can capture these FAT results as transactions and record the results asvalidated blocks in the machine's public blockchain, which is sharedwith blockchain node devices at the manufacturing facility.

After the machines have been deployed at the manufacturing entity 1904,industrial blockchains can be used to track each machine's performance.For example, during bottling and filling operations at the manufacturingentity 1904, blockchain-enabled industrial devices 1102 at the facilitycan generate and update both private blockchains 1304 b that recordproduction data intended for internal use only, as well as publicblockchains 1304 a comprising transaction data that can be accessed andviewed by devices associated with the relevant OEM. The manufacturingentity's private blockchain data may comprise, for example, proprietaryinformation relating to the product being manufactured within themanufacturing facility (e.g., recipe data, product order information,product quality check results, etc.), while the public blockchain dataaccessible by the OEM may include only performance statistics associatedwith the particular machine that was built and provided by the OEM(e.g., machine downtime statistics, alarm histories, etc.). This allowsthe OEMs to track performance of their own custom-built machines withoutbeing privy to the manufacturing entity's proprietary manufacturing dataor information regarding other OEMs' machines. If desired, theblockchain-enabled industrial devices 1102 that make up the variousmachines of a production line or facility can be configured to maintainseparate private blockchains for each OEM, so that performance ofmachines provided by different OEMs can be compared by the plant owner.

This selective sharing of blockchain data can also be used to generate areliable tamper-proof ledger of machine usage statistics, which can beused in connection with subscription-based models of machine usage. Forexample, rather than purchasing a machine from an OEM, the manufacturingentity 1904 may establish a subscription-based contract with the OEM touse the machine at the manufacturing facility and to pay the OEM basedon usage (e.g., based on an amount of monthly run-time, product count,power cycles, energy consumption, etc.). In some implementations, termsof this machine subscription service can be enforced by a smart contractdefined for the blockchain ecosystem comprising the manufacturing entity1904 and the OEM (supplier entity 1902). During runtime,blockchain-enabled industrial devices 1102—which can include bothdevices of the machine itself (e.g., industrial controllers, telemetrydevices, power meters, drives, etc.) as well as other industrial devicesor systems owned by the plant (e.g., power meters, ERP systems,etc.)—can track and record usage statistics for the machine as atamper-proof blockchain that is shared with blockchain node devices atthe OEM, eliminating the possibility of disputes between themanufacturer and OEM regarding actual machine usage.

Usage and/or status data recorded in the blockchain can also bemonitored to determine when components of the machine should bereplaced. For example, the smart contract can include provisions for theOEM to replace certain machine components or devices after a definednumber of production cycles (or based on another time-based orevent-based criterion, such as total energy consumption, part count,downtime or alarm frequency, a KPI setpoint, etc.). In response to atransaction indicating that the part replacement event has occurred, oneor more systems within the blockchain ecosystem (e.g. system 2106described below in connection with FIG. 21, or another system) canautomatically initiate procedures for verifiably purchasing anddelivering the replacement component (e.g., generating a purchase order,submitting the order to a vendor, scheduling an on-site visit by the OEMto replace the component, etc.). Similar to techniques described abovein connection with FIG. 8, some embodiments of blockchain-enabledindustrial devices 1102 may require submission of processing “fees”(e.g., Ether or “gas”) in exchange for execution of smart contract logicon relevant transactions.

An example workflow for facilitating device replacement within thecontext of an OEM service agreement is now described. In an examplescenario, an OEM may build a custom machine for a manufacturing entity.Typically, the machine will comprise the controlled mechanical system aswell as the electrical and control system that distributes power to themachine components and facilitates automated control of the machine. Thecontrol system is generally housed in a control cabinet and can includea number of industrial control devices, including but not limited to oneor more industrial controllers, motor drives (e.g., variable frequencydrives), or other such industrial devices. In this example, theindustrial control devices are blockchain-enabled devices.

During the building phase at the OEM facility, verifiable, uniqueidentities of the machine components used in the machine assembly arerecorded in the ledger of a public blockchain (similar to publicblockhains 1304 a illustrated in FIG. 19) stored on one or more of theindustrial control devices to be shipped with the machine. A unique,verifiable identity for the machine itself is also recorded in thepublic blockchain ledger. Since the industrial controller will typicallyexecute a custom control program or application developed by the OEM,the public ledger will also include a verifiable record of this controlapplication. This record of the control application may be signed by theOEM's private key. Additionally, records of certain vendor-specificcomponents used in the machine can be recorded in the public ledger. Forexample, the firmware version currently installed on the industrialcontroller or another industrial device in the machine's control cabinetmay be recorded in the public ledger and signed by the vendor's privatekey.

In accordance with a contractual agreement between the OEM and themanufacturing entity (the purchaser), the OEM agrees to replace one ormore specified component parts of the machine after completion of adefined number of machine operating cycles. The number of operatingcycles that is to trigger a part replacement is defined on at least oneof the machine's control devices (e.g., the industrial controller in thepresent example).

During operation at the manufacturing entity's facility, theblockchain-enabled industrial controller tracks a number of productionstatistics, including an accumulated number of operating cyclesperformed by the machine, an accumulated amount of time that the machinehas run, a number of parts produced by the machine, etc. The industrialdevices of the machine's control cabinet record this production data inthe public blockchain ledger, signing the production data using themanufacturing entity's private key. The control devices also recordmodifications made to the machine or its associated industrial devicesby the manufacturing entity. For example, changes made to the firmwareof the industrial controller or other control devices as a result ofreimaging or patching are recorded in the public blockchain ledger, asare modifications made to the OEM-developed control program orapplication executed on the industrial controller.

In response to determining that information stored in the public ledgersatisfies a criterion (e.g., a criterion defined in a smart contract)indicating that the OEM is contractually obliged to perform a componentreplacement or other maintenance action on the machine (e.g., inresponse to execution of a defined number of machine cycles, when theaccumulated machine run time exceeds a defined number of operatinghours, when the machine has produced a defined number of parts, etc.),the block chain engine in the industrial controller signs, on behalf ofthe owner, a verifiable and contractually binding component replacementorder as a transaction in the public blockchain.

Since the OEM has access to data stored in the public blockchain, theOEM receives and verifies the component replacement order, and inresponse ships the necessary machine component to the manufacturingentity. The manufacturing entity installs the replacement component andrecords a signed conformation of the replacement in the publicblockchain ledger. The OEM can use this verified transaction to initiatepayment processing. Using this system, the replacement component, thevendor-specific device firmware, and the OEM-specific application areall verifiably tracked in the public blockchain ledger. The currentstate reflected in the public blockchain reflects the authorizedproduction cycle count, which is viewable by both the OEM and the enduser. For subscription-based operation of the machine, the OEM canauthorize the production cycle count in the public blockchain ledgerbased on payment and agreement. The end-user can also set the criteriafor the machine to automatically renew additional productionauthorization at defined thresholds.

In addition to the information recorded in the public blockchain ledgeras described above, the machine's control devices also maintain aprivate blockchain ledger (e.g., private blockchains 1304 b in FIG. 19)comprising data that can be accessed only by the manufacturing entity.This can include smart contracts for the authorization of machinedowntime, approval of new firmware versions, and approval of newversions of the control application. These authorizations can beperformed by the blockchain engines of the industrial devices withoutrelying on a human entity to tell the machine to do so.

The private blockchain for the machine can also include records ofmaintenance operations performed on the machine that do not affect theOEM contract (e.g., maintenance operations that do not involve modifyingthe OEM's control application, replacing components that the OEM isobliged to replace, etc.). These maintenance records can also includerecords of which personnel performed the maintenance operation and whenthe maintenance operations were performed.

The private blockchain can also include machine operation statisticsthat do not affect the OEM contract. Such production information caninclude, for example, identifications of plant employees who operatedthe machine during each shift, stoppage times during each shift, totalmachine runtime for each shift, etc. Other information that can bestored on in the private blockchain can include, but is not limited to,internal manufacturing information such as part identities (e.g., chipserial numbers used on an assembled printed circuit board), part defectstatistics, improper machine operations, etc.

Other types of entities involved in purchase or leasing of a machinefrom an OEM can also be included as participants in the industrialblockchain ecosystem. For example, as part of the process of installinga new production line, plant owners may obtain financing from a bank orpurchase design services from an engineering firm. Like the OEM, theseother entities may be paid by the manufacturing entity 1904 inincrements; e.g., based on project milestones or on a periodic basis.Public industrial blockchains generated by devices 1102 can allow allparties to see the progression of the machine build project as themachine moves toward operation, with states of the project being trackedand recorded in the blockchain. Access to the data recorded by theblockchain can be regulated based on the role of the entity. Forexample, the OEM may be interested primarily in production numbers forbilling purposes in a subscription-based contract, while designers maybe afforded access to more granular device-level performance data. Thediverse entities involved in the machine's lifecycle (e.g., designer,OEM, manufacturer, financial institution, etc.) can each be affordedlayered levels of access to blockchain data generated for the machine atall stages of its lifecycle (e.g., design, commission, operation, andmaintenance).

The public and private industrial blockchains can also be used toimprove technical support services offered by the OEM or by othersupport entities. For example, if a machine downtime event or otherperformance issue is reported by the manufacturing entity 1904, theblockchain transactions can be examined by the OEM or other technicalsupport entity to determine the state of the customer's machine at thetime of the reported event. Information encoded in the blockchain thatmay be leveraged by the technical support entity can include, but is notlimited to, device identifiers, device configuration data, machinestates, etc. The customer's shared blockchain can also log unscheduledmaintenance events, skipped lock out/tag out events, or other operatoractions that may be useful to technical support entities when tracking aroot cause of a reported performance issue. As in previous examples,blockchain-enabled industrial devices 1102 can maintain publicblockchains that record transaction data accessible to outside technicalsupport entities, while separately maintaining a private blockchain thatrecords proprietary information that is inaccessible to the technicalsupport entity. The public blockchain can be made accessible to allrepair entities that are trusted members of the industrial blockchainecosystem.

In a related aspect, blockchains generated for the machine (by theblockchain-enabled devices that make up the machine as well as by otherperipheral systems such as ERP and MES systems) can be leveraged toperform machine warranty and maintenance tracking. For example, themachine's blockchain can record usage and repair information on themanufacturing entity's plant intranet. This information can include, forexample, dates and times at which a maintenance operation was performed,identities of any components or devices that were replaced orreprogrammed, dates and times of lock out/tag out procedures that werefollowed in connection with a maintenance action, identities of thepersonnel who performed the maintenance action, etc. The blockchain thatrecords this maintenance information can be maintained on distributeddevices within the manufacturing entity's plant intranet, such that anysingle device on the plant's blockchain network can query the blockchainto obtain maintenance log information for the machine. This creates atamper-proof record of maintenance operations that can be accessedwithout the need to log into a data historian. Some of this maintenanceand operational information can be maintained on a private blockchainthat is only accessible by devices on the plant's own intranet.Additionally, blockchain-enabled devices 1102 within the plant cangenerate a public version of the machine's blockchain that includeswarranty-related information that is accessible by outside supportentities (e.g., OEMs or other technical support entities) who have abusiness interest in the information. Information in this public versionof the blockchain can include, for example, operating hours, powercycles, identities of devices added to the machine (which may beunauthorized devices), etc. This public version of the machine'sblockchain can be viewed by outside support entities to validate claimsmade by the machine owner regarding internal maintenance actionsperformed on the machine or the machine's operational history.

The techniques described above regarding the use of industrialblockchains to track an OEM-provided machine across its lifecycle canalso be applied to parts, sub-assemblies, or materials provided bysupplier entities 1902 to a manufacturing entity 1904. For example, theblockchain systems that make up an example industrial blockchainecosystem may be geographically distributed across multiple businessesthat together form an integrated supply chain for a product. In anautomotive example, sub-assemblies for a car produced by an automotivefacility (the manufacturing entity 1904 in this example) may bemanufactured by respective sub-assembly suppliers (supplier entities1902). In addition to generating private blockchains 1304 b that recordproprietary manufacturing data generated in connection with thefabrication of the sub-assemblies, blockchain-enabled industrial devices1102 at the supplier entities 1902 can generate public blockchains 1304a that record information regarding manufacture of the sub-assembliespermitted to be shared with the manufacturing entity 1904. These publicblockchains 1304 are accessible by devices at the manufacturing entity1904, and only comprise a subset of available sub-assembly manufacturinginformation that the supplier is contractually obligated to provide tothe manufacturer. This public blockchain information can be incorporatedinto the manufacturer's own information tracking for the fully assembledand sold vehicles.

Also, similar to the OEM example described above, public blockchains1304 a that record transactions at the manufacturing entity 1904 can beused to share a selected subset of performance or test data for thesesub-assemblies with their associated supplier entities 1902, allowingthe sub-assembly suppliers to track the performance of their ownsub-assemblies after the sub-assemblies have been sent to themanufacturer.

Blockchain-enabled industrial devices 1102 can also be configured tosupport the use of blockchains in connection with distribution ofproprietary recipes between supply chain entities and execution of thoserecipes on industrial controllers. A recipe may comprise a set ofexecutable instructions and/or parameter values for manufacturing aspecific type of product or material. When installed and executed on anindustrial controller, the recipe instructs the controller how toproduce the specified product or material. While many recipes aredesigned by engineers within the plant facility that produces theproduct, in some cases the recipe may be a proprietary set ofinstructions and/or parameters designed and distributed by an outsideentity. In an example scenario, an OEM may design and distribute recipesto manufacturing customers that have purchased or leased the OEM'sproprietary equipment, so that the OEM's recipe can be executed on theequipment in connection with manufacturing a particular type of product.In another example, a manufacturing entity may provide a recipe to asupplier entity to ensure that component parts or materials manufacturedby the supplier for the manufacturing entity meet specificationrequirements. The provider of the recipe may wish to keep the details ofthe recipe hidden from the receiving entities that utilize the recipe toproduce a batch of product. From the opposite perspective, the entitythat receives and installs the recipe on their equipment requiresverification that the recipe being installed is from a trustworthysource.

Accordingly, industrial blockchains can be used to ensure to themanufacturing entity that a recipe is from a trusted source and to trackexecution of the recipe on the end manufacturing entity's equipment. Theblockchain can also track changes made to the recipe itself. In anexample scenario, a recipe holder—such as a supplier entity thatdevelops and provides recipes for execution at partner facilities—candeliver a signed, verifiable recipe to the recipe user (themanufacturing entity that will execute the recipe on one or moreindustrial controllers to yield a product or material in accordance withspecifications encoded in the recipe). The recipe may be contractuallybound to produce a specified number of units or batches, or may have anassociated timed expiration beyond which production rights afforded tothe recipe user expire. The recipe to be distributed to the supplierentity can be embedded in a blockchain, and a public key infrastructure(PKI) system (implemented by the cryptographic components 1106 of theblockchain-enabled industrial devices 1102 and using private keys 1122and public keys 1124) can be used to ensure that the recipe is executedonly on a specified target device (e.g., a specified industrialcontroller 1210). For example, a sending device can wrap the recipe witha private key to yield an encrypted recipe, and the cryptographiccomponent 1106 of the receiving controller (e.g., controller 1210) onwhich the recipe is to be executed can unwrap the encrypted recipe withits own private key 1122 using the public key. Blockchain-enabledindustrial controllers 1210 at the recipe user's facility can beconfigured to leverage the blockchain information to verify that therecipe is from a trusted source (the recipe holder) before executing,and to verify that the controller itself has been authorized to executethe recipe. Controllers 1210 can also execute the recipe withoutpermitting the recipe holder to view the specifics of the recipe. Inthis regard, the blockchain-enabled system may place intentionallyobfuscated ingredient orders through the recipe maker's supply chain.

In some embodiments, a licensed contract to use the recipe can also beembedded (e.g., as a smart contract enforced by industrial devices 1102that make up the industrial blockchain ecosystem) to prevent executionof the recipe on the recipient's controller after an agreed number ofparts have been produced using the recipe (or based on anothertermination criterion, such as a specified expiratory date, consumptionof a specified amount of power by the controlled system, etc.).Geotagging can also be used to verify that the recipe is being executedat an agreed location (e.g., at a specified plant facility). In suchembodiments, the recipe can be made aware of its location based ongeotagging functionality of the industrial device 1102 on which therecipe is executed, and will only allow execution by the industrialdevice 1102 if the geotagged location corresponds to the agreedlocation.

In such recipe sharing systems, when the recipe is delivered, the publicledger of the industrial blockchain—which can be accessed by both therecipe owner and the recipe maker—may include the signed and verifiedrecipe, the authorized number of production units or batches and/or theauthorized period of production. During production, the public ledgercan also record the elapsed number of units produced and/or the elapsedruntime for the recipe. At the recipe maker's facility,blockchain-enabled industrial devices are configured to validate therecipe, to interpret the obfuscated recipe, to take the productionorder, and to determine the quantities and ingredients needed to executethe recipe. The blockchain-enabled devices can also control theproduction process by placing ingredient orders through the supply chainto the recipe maker. Also, during production, the blockchain-enableddevice 1102 can also maintain a private blockchain ledger that isvisible only to the recipe maker, and includes proprietary recipeoperations information, including but not limited to batches ofdifferent recipes for different recipe owners, private end userproduction statistics not covered by the recipe contract, privatemachine operational information (e.g., identities of plant personnel whooperated the machine, runtime statistics for the machine, downtimestatistics for the machine, etc.), internal manufacturing information,defect tracking statistics, and other such proprietary information.

In general, selective access to public and private industrialblockchains can be granularized as needed. For example, fully publicindustrial blockchains can render their associated transaction dataavailable to all entities and devices that make up the blockchainecosystem. Blockchain-enabled industrial devices 1102 can also supportsemi-public industrial blockchains that allow transaction data to beshared only with a specified subset of all entities within theindustrial blockchain ecosystem (e.g., as in the OEM and sub-assemblysupplier examples described above, in which the public blockchains areonly made accessible to the relevant OEM or supplier). Similarly,private blockchains 1304 b that only share transaction data amongdevices within a given industrial facility or industrial enterprise(e.g., among devices on a plant's intranet) may be accessed according toa layered access permission model. For example, some private industrialblockchains may be shared among all participating devices on a plant'sintranet, while other private industrial blockchains may be shared onlyby a subset of devices that are associated with a given production areaor production line.

Public and private industrial blockchains can also be used to trackmanufactured products through a manufacturing facility or acrossmultiple facilities of an industrial enterprise. FIG. 20 is a diagramillustrating generation of blockchain data within a plant intranet. Themanufacturing facility depicted in FIG. 20 may correspond, for example,to manufacturing entity 1904 or one of the supplier entities 1902depicted in the supply chain ecosystem of FIG. 19. In the illustratedexample plant architecture, a number of production areas 1306 within amanufacturing facility—including Production Area 1 and Production Area2—produce component parts or materials that are provided to ProductionArea 3, which assembles the parts or materials received from thoseupstream production areas. During runtime, blockchain-enabled industrialdevices 1102 that operate within Production Areas 1 and 2 (the supplierproduction areas) bundle transactions generated within their respectiveproduction areas in connection with production of the component parts ormaterials, generate and validate blocks of these transactions (e.g.,collaboratively with other blockchain-enabled industrial devices 1102within the respective production areas using consensus-based validationtechniques such as practical byzantine fault tolerance, proof-of-work,or proof-of-state), and add the validated blocks to a private blockchain1304 b that is only accessible to participating devices on the plant'sintranet (and not to other entities of the larger blockchain ecosystem).

Component parts or materials produced by Production Areas 1 and 2 areconveyed to Production Area 3 for assembly into either a finalizedproduct or a sub-assembly of the final product. The blockchain-enabledindustrial controller 1210 (or another blockchain-enabled industrialdevice 1102) that controls the industrial assets in Production Area 3can link the blockchains generated by Production Areas 1 and 2, whichare associated with the respective component parts generated in thoseproduction areas. In an example system, the plant may be a bottlingfacility, and three upstream production areas (including ProductionAreas 1 and 2) may respectively produce a bottle, a cap, and a labelwhich are then assembled at Production Area 3. When a received bottle,cap, and label are assembled at Production Area 3, theblockchain-enabled industrial controller 1210 that monitors and controlsthe Production Area 3 automation system can synchronize and link theblockchains associated with each of the components that were generatedat the respective upstream production areas, yielding a compositeblockchain for the assembled product (a capped and labeled bottle). Thedevices of Production Area 3 can also expand this composite blockchainby adding records of its own operations performed on the assembledproduct. As part of the controller's initial configuration, a ledgerdesign tool (e.g., a tool of device configuration application 1208) canallow the user to define what information is to be included in theledger (e.g., ledger 1126), and to select which automation objectinstantiated in the controller 1210 is to be used as the ledger root.

In some implementation, each assembled product can be represented by anew block in the industrial blockchain, with each block's transactiondata comprising production statistics for the product. Examplestatistics that can be archived in the blockchain can include, but arenot limited to, a part identifier (e.g. a VIN number of an assembledvehicle, a serial number of a capped and labeled bottle, etc.), atimestamp indicating a time of assembly or manufacture, measured qualitymetrics (e.g., leak test results, cap or bolt torque data, etc.),machine states or telemetric data at the time the product was assembled(e.g., oven temperatures, moisture levels, water or air pressures,etc.), or other such information that can be married to a unit or batchof product. In some implementations, each operation performed on theunit of product during its progress through the production process canbe represented as a transaction within the industrial blockchain.

This technique for linking industrial blockchains associated withcomponent parts of a final assembled product can be extended to includeparts, sub-assemblies, or materials received from outside supplierentities, and more generally to traversal of products across the entiresupply chain (e.g., the supply chain depicted in FIG. 19). In suchscenarios, supplier-provided components (e.g., batches of material,sub-assemblies, component parts, etc.) can be received at themanufacturing facility together with blockchains that recordtransactions associated with production of the components at thesupplier sites. One or more blockchain-enabled industrial devices 1102at the manufacturing facility can link these blockchains into acomposite blockchain, adding its own transactions to the blockchain asnew blocks as the received components are further assembled and/orprocessed. When the product leaves the manufacturing facility andarrives at the next entity in the supply chain (e.g., anothermanufacturing entity, a warehouse entity, a shipping entity, a retailer,etc.), any new transactions performed on the product at the next entityare added to the existing blockchain data associated with the product(including synchronized blockchain data associated with any of theproduct's sub-assemblies or component parts), either by adding newblocks to the existing blockchain or by synchronizing and linking theexisting blockchain for the product with a new blockchain generated atthe next entity to capture new transactions carried out on the product.In addition to manufacturing transactions, the composite industrialblockchain associated with the unit of product can also record producthandling and location tracking information (e.g., warehouse shippinginformation) as well as business-related information (e.g., orderinformation, purchase information, etc.). All of these diversetransactions are validated by a consortium of devices within theindustrial blockchain system or ecosystem using suitable consensus-basedvalidation techniques.

In another example configuration, an industrial blockchain generated fora component part to be assembled with other parts into a final productcan include, in addition to production statistics for the componentpart, provenance information that defines, as immutable and verifiedblockchain data, an origin or source of the component part. Thisprovenance information can comprise, for example, one or more of anidentity of a vendor or supplier of the component part, a partidentifier, identifies of other entities within the supply chain throughwhich the part has traversed, a date of the part's manufacture, a costof the part, or other such information. The part's blockchain can alsoinclude part characteristic information about the part, including butnot limited to a type of the part, a color of the part, a composition ofthe part, a size of the part, or other such information.

One or both of the provenance information or the part characteristicinformation stored in the component part's blockchain can be leveragedby industrial devices at the manufacturing site to verify, prior toassembly of the part into the final product, that the correct part isbeing incorporated into the final product. For example, with referenceto the example production facility depicted in FIG. 20, when componentparts are received at Production Area 3 for assembly into either asub-assembly or a final product, one or more industrial devices atProduction Area 3 can be configured to incorporate a component part intoa product assembly or sub-assembly only if the provenance and/or partcharacteristic information stored in the component part's blockchainsatisfies one or more defined criteria. These criteria can define, forexample, authorized sources or dates of manufacture of the componentpart (which can be verified based on reference to the provenanceinformation); correct part types, sizes, and/or colors (which can beverified based on reference to the part characteristic information), orother such criteria. During operation, when component parts are receivedat Production Area 3 for assembly into either a sub-assembly or a finalproduct, the one or more industrial devices will reference theprovenance and/or part characteristic data recorded in the parts'respective blockchains, determine whether the recorded informationsatisfies the defined assembly criteria, and proceed to incorporate eachcomponent part into the assembly only if the provenance and/or partcharacteristic information for the part satisfies the criteria. When theassembly is complete, the industrial devices can merge the provenanceinformation for the component parts that were used in the assembly toyield composite as-built provenance information for the assembly as awhole, and record this as-built provenance information in a blockchainassociated with the assembly.

In some implementations of this system, industrial devices that processa given component part can obtain some or all of the provenanceinformation or part characteristic information for the part from aradio-frequency identifier (RFID) tag attached to or otherwiseassociated with the part. In such embodiments, items of provenanceand/or part characteristic data can be written to the RFID tagassociated with the part at certain points during traversal of the partthrough the supply chain. This information can subsequently be read fromthe part's RFID tag by one or more RFID readers and added to the part'sblockchain as a transaction.

Systems that support aggregation of component part blockchains intoaggregate blockchains associated with a sub-assembly or final assembledproduct, as described above, can also leverage these aggregate assemblyblockchains in connection with warranty returns. For example, amanufacturing entity that produces and ships a sub-assembly or assembledproduct can store, as immutable composite blockchains, assemblyinformation identifying the various component parts that were used inthe assembled product. This assembly information can include some or allof the provenance and/or part characteristic data described above. Thiscomposite assembly information can subsequently be checked to determinewhether an assembled product that has been returned for repairs orreplacement under warranty has been altered or tampered with by thecustomer. In the case of assembled products comprising RFID-taggedparts, this determination can be made by reading RFID data from thecomponent parts that make up the returned product to determine theas-returned composition of the product, and comparing this as-returnedcomposition with the as-built composition recorded in the assembledproduct's blockchain. An RFID tag reader interfaced to one or moresources of the plant's blockchain data can be configured to make thiscomparison and to output information identifying anomalous parts or partreplacements present in the as-returned composition. Depending on theterms of the warranty, the manufacturing entity may choose to eitherdeny or proceed with the repair or replacement. For example, thewarranty may dictate replacement of one or more specified componentparts by the end user is permitted and does not violate the terms of thewarranty. If the system determines that only such component parts havebeen replaced, the replacement or repair may be permitted.Alternatively, if the system determines that a component part replacedby the end user violates the terms of the warranty, the replacement orrepair may be denied.

To minimize consumption of storage space, some embodiments ofblockchain-enabled industrial devices 1102 can allow users to configureselected blockchains for a product to be transient rather thanpersistent, such that the blockchains will be deleted after anexpiration time or on an event basis. For example, a blockchaingenerated for a particular item or batch of product may be configured todelete itself from all devices across which the blockchain isdistributed after a defined criterion has been satisfied. For example,the industrial blockchain associated with an item of perishable productcan be configured to delete itself after an elapse of a time durationafter which it can be assumed that the product was consumed (e.g., threemonths after the product is sold, as determined based on credit cardtransaction data). In another example, the blockchain associated with aproduct may be configured to delete itself after the product leaves themanufacturing facility if the blockchain's data only has utilityinternally during the manufacturing process. Automatic deletion of anindustrial blockchain will extend back to the blockchain's root toensure that blockchain's data can still be validated. Alternatively,when the deletion event occurs, the blocks of the blockchain can bemaintained while the associated transaction data is deleted, or a newroot can be set such that a later portion of the blockchain remainswhile an earlier portion is deleted. The portion of the blockchain thatis deleted can be dependent on the blockchain's hierarchy. In anotherexample configuration, a blockchain's expiration definition can specifythat only a selected subset of participating devices—those not requiringthe blockchain's data—may delete the blockchain in response to thedeletion event, while other devices may maintain the blockchain. In anexample scenario, a blockchain-enabled industrial controller may notneed a product's blockchain after the product leaves the production areaand deletes the blockchain accordingly (e.g., in response to recordedshipping information that indicates the product has left the facility),while an MES system may save the blockchain for archival purposes.

Since a product may pass through several different supply chainentities, some embodiments of blockchain-enabled industrial devices 1102can include contingency features for managing gaps within the product'sblockchain. These gaps can occur, for example, when the product leavesone facility and is transported to another location in the chain via atruck with no communication capabilities. In some embodiments,artificial intelligence or other types of inference can be used to inferthe missing information. When the product reaches another verifiedentity within the supply chain, historical information can be leveragedto interpolate and confirm that the product is back under control of anauthenticated entity.

In addition to the private blockchains 1304 b, the blockchain-enabledindustrial devices 1102 at the manufacturing facility can also generatepublic blockchains 1304 a that record, as transactions, manufacturingstatistics for each unit of product that is to be shared with otherdevices on the larger industrial blockchain ecosystem. These publicindustrial blockchains 1304 a can be distributed across devices at theindustrial facility and devices associated with other entities in theecosystem (e.g., a supply chain), which are connected via a public orsemi-public network 2002 such as the internet or a public or privatecloud platform. Public industrial blockchains 1304 a can includeblockchains that are to be accessible by all participants in theblockchain ecosystem (i.e., fully public blockchains) as well assemi-public blockchains that are to be accessible only by selectedentities and/or devices in the ecosystem. In this regard,blockchain-enabled industrial devices 1102 can be configured to generateas many different tiers of blockchains as desired, with each blockchaindefined and configured to permit access by a selected set of entities.

In an example scenario, the manufacturing facility may manufactureproducts for multiple different customers (e.g., a plant that producescustom computer chips for different computer manufacturers).Accordingly, blockchain-enabled industrial devices 1102 used tomanufacture the products may be configured to create a proprietarycustomer-specific blockchain for each customer, which eachcustomer-specific blockchain comprises transaction data associated withthat customer's product. In such implementations, the blockchain-enableddevices 1102 can create a new blockchain for each customer-specificmanufacturing run. That is, after a production line switches operationfrom production of a batch of product for a first customer to a newbatch for a second customer, the blockchain-enabled devices will ceaseupdating the previous blockchain associated with the first customer'sproduct and begin a new blockchain for the second customer to recordtransactions associated with the new product run. In this way,industrial devices participating in the blockchain system can segregateindustrial blockchains according to customer.

In addition to maintaining separate blockchains for a given product ormachine, with each blockchain having different access permissions, someembodiments of blockchain-enabled industrial devices 1102 can beconfigured to manage selective access to a given single blockchain. Forexample, an industrial blockchain can be generated that allows theblockchain's hash information to be made public to all entities withinthe ecosystem while keeping the blockchain's transaction data private.This can allow a manufacturing entity to reassure outside parties thatthe plant's data is authentic without providing visibility into the dataitself (which may be proprietary). In an example scenario, an OEM mayvouch for a state of a machine or program, which can be confirmed bychecking the publicly accessible hash values of the machine'sblockchain. This hash information can be made available without allowingprivate information about the machine state itself to be viewed byentities outside of the OEM.

To ensure trust relationships between blockchain-enabled industrialdevices 1102 that make up an ecosystem 1702 of industrial blockchainsystems 1704 (e.g., a supply and/or distribution chain), a trustedentity can certify device vendors that produce blockchain-enabledindustrial devices 1102 and that participate in the supply chain,creating a supply chain with signed participation. In general,blockchain-enabled industrial devices 1102 are configured toauthenticate transactions (e.g., using digital fingerprinting or byother authentication means) within the global supply chain workflow,including transactions that occur within the manufacturing facility inwhich the transactions occur (e.g., transaction in which the industrialdevices 1102 are directly involved) as well as transactions thatoriginate elsewhere in the supply chain (the industrial blockchainecosystem) as part of a consortium comprising multiple industrialdevices 1102. As an example consensus criterion, a rule can be definedstating that at least 20 devices on the blockchain network must agreethat a transaction is valid before adding the transaction to a block.

The use of blockchains throughout the supply chain, as described inprevious examples, can also allow a consortium of entities toauthenticate standards for a product from many levels. For example,different entities within an industrial blockchain ecosystem can certifythat a product meets a defined standard in terms of safety, laborpractices, equipment used to manufacture the product, certified plantsat which the product was manufactured, etc. The devices making up theconsortium can act as a mesh network, where different sub-entities canconfirm that the defined standards are being met across multiple supplychain jurisdictions (e.g., that a product is organic, that a materialused in the product is authentic, etc.). In an example scenario, torecord that a product has been authentically produced by a certifiedplant and/or using legitimate equipment (e.g., certified machines orother approved industrial devices), the blockchain-enabled industrialdevices that were involved in producing the product can record, as atransaction in the product's blockchain, validated identities of theblockchain-enabled industrial devices themselves. In some embodiments,this recorded device identity information can include both identityinformation for the device itself (e.g., model number, unique serialnumber, etc.) as well as an identity of the plant entity that owns theequipment. Recording this information as a blockchain transactioncreates a tamper-proof, verifiable authentication that the product wasproduced by approved or certified equipment. In this way, the use ofindustrial blockchains can simplify the process of tracking compliancepaperwork through multiple jurisdictions and ensure the authenticity ofsuch claims.

Industrial blockchains can also be used to authenticate carbon creditsby tracking how much carbon dioxide was used to manufacture a product.In an example implementation, all carbon dioxide consumption can beaggregated by the blockchain-enabled devices 1102 and added as avalidated element of the blockchain. This trusted and validatedconsumption data can be submitted to appropriate regulatory agencies forcarbon dioxide credits.

Both within the context of a single manufacturing facility (e.g., thesystem depicted in FIG. 20) as well across an entire supply chainecosystem (e.g., the ecosystem depicted in FIG. 19), multipleblockchains may be generated and aggregated during manufacture of aproduct or during traversal of the product through the supply anddistribution chain. Some industrial blockchain systems can leveragethese aggregated blockchains to correlate events within the facility orsupply chain or to identify a chain of events. Accordingly,blockchain-enabled industrial devices 1102 or associated analyticsystems can identify temporal relations between transactions amongdifferent blockchains. This can involve real-time synchronization ofindustrial blockchains for historian analysis. Analysis of synchronizedindustrial blockchains can assist with the process of identifying rootcauses of machine failures, product defects, or other issues. Forexample, an associated industrial blockchain analytic system can analyzea slice of time across multiple synchronized blockchains and identifychains with commonality in connection with identifying a root cause of asupply chain or manufacturing event of interest.

To facilitate root cause analysis, blockchains generated by industrialdevices 1102 can be configured to capture transactions relating tooperation and statuses of machines or production lines themselves. Thesemachine history blockchains may be separate from those that capturetransactions relating to manufacture of a product per se, and maycapture, from the industrial devices and assets making up amanufacturing facility or supply chain, such information as diagnosticdata, operating mode information, machine downtime durations and times,alarm information, telemetric data, or other such information. Theseblockchains can also capture records of maintenance actions, includingbut not limited to lock out/tag out actions, records of device orcomponent replacements, operator actions gleaned from interactions witha control panel or HMI, or other such information. By capturing suchinformation as blockchain transactions, industrial blockchains cancreate a tamper-proof ledger of information indicative of an exact stateof a plant at any point in time. This information can be used inconnection with troubleshooting issues within a facility or supplychain. These machine history or equipment history blockchains can alsobe correlated with the product-specific blockchains described above inorder to determine a state of a machine or set of industrial assetscorresponding to one or more manufactured products of interest. Forexample, if the blockchain transaction data for an item of manufacturedproduct indicates a quality concern, this product-specific blockchaincan be correlated in time with the machine-history blockchain for theproduction line responsible for manufacturing the product in order todetermine if a state of the equipment that produced the product isrelevant to the quality concern.

In an example implementation, a set of blockchain-enabled industrialdevices 1102 that make up an industrial blockchain system can beconfigured to generate a plant model blockchain that models theproduction lines, machines, hardware components, and/or softwarecomponents (e.g., firmware versions, application versions, etc.) thatmake up a manufacturing facility (or a production area within thefacility). Devices 1102 can assemble these blockchains as the productionlines and machines are powered up and the associated sets of equipmentreport their identity and status information. The devices 1102 canrecord this identity and status information for all devices within theplant model blockchain, yielding a Merkle tree of hashes in which eachelement of the tree represents an item of equipment. This plant modelblockchain can record, for each device, such information as modelnumbers, software or firmware revision numbers, configuration settings(e.g., controller or variable frequency drive settings), operating modeinformation, maintenance log information, safety device statuses, totalaccumulated runtime data, operating modes, or other such device or assetinformation.

During plant operation, the plant model blockchain can record changes tothe states of the devices and/or machines within the plant, treatingeach change of a device's state as a transaction to be recorded in theplant model blockchain. In this way, the plant model blockchain canrecord changes to machine operating modes, changes to a device'sfirmware or software, changes in states of industrial safety devices,abnormal conditions, diagnostic data, lock out/tag out actions, statesof safety lock switches, states of operator panel control devices (e.g.,pushbuttons, switches, etc.), sensor states (e.g., part presenceindications), or other such information. Thus, the plant modelblockchain creates a verified history of the of the plant's overallstate, as defined by the aggregated states of the devices and machinesthat make up the plant. In some implementation, the plant modelblockchain may comprise multiple synchronized blockchains correspondingto different production areas or machines within the plant. Analysistools can be used to analyze these plant model blockchains to identify achain of cause-and-effect events, or to determine a root cause of anevent (e.g., a machine failure, detection of a product defect, etc.). Inan example general technique, such analysis tools can identify andanalyze a slice of time corresponding to an event of interest across themultiple synchronized plant model blockchains, and identify chains withcommonality in connection with identifying the root cause of the event.

These plant model blockchains can also be referenced in connection withdevice replacements within the plant. In this regard, since the statesand configurations of industrial devices currently deployed within theplant facility are recorded within a plant model blockchain, thisinformation can be accessed to determine the correct firmware and/orapplication that should be installed on a new device that is to replacean existing device. Tracking this information using industrialblockchains can ensure that this replacement device configurationinformation is reliable, preventing misconfiguration of replacementdevices prior to deployment

This plant modeling technique can also be leveraged on a smaller scaleto track states and events at the control cabinet level. In an exampleimplementation, blockchain capabilities (e.g., blockchain engine 1128)can be implemented on motor drives (e.g., variable frequency drives orother types of motor drives) that are mounted within a motor controlcabinet (MCC). This can allow the states of the MCC to be tracked,recorded, and analyzed.

Since the industrial blockchain paradigm records transactionsoriginating at one industrial asset or device in a decentralized manneracross multiple blockchain-enabled devices, each participatingindustrial device has a degree of visibility into the operation of otherdevices or systems by virtue of the distributed ledgers 1126 sharedacross the devices. In some embodiments, blockchain-enabled industrialdevices 1102 can incorporate information in this distributed ledger 1126into the device's control strategy. For example, as noted above, theblockchain-enabled industrial controller 1210 depicted in FIG. 18executes a control program 1204 (e.g., a ladder logic program or othertype of control program) in connection with monitoring and controllingan industrial machine, system, or process 1320 via I/O 1308. Sinceindustrial controller 1210 supports blockchain functionality, thecontroller 1210 maintains one or more blockchain ledgers 1126corresponding to public and/or private industrial blockchains 1304 thatrecord transactions (e.g., industrial events, manufacturing and supplychain activities, etc.) within the blockchain system and/or ecosystemwithin which the controller 1210 participates. Each ledger 1126 recordsnot only transactions that originate on the controller 1210 or itsassociated controlled process 1320, but also validated transactions(received as transaction data 1324 or ledger deltas) that originate atother devices or systems that participate in the blockchain system orecosystem (e.g., other blockchain-enabled industrial devices associatedwith other production areas or machines within the plant, or devicesassociated with other entities of the supply chain outside the plant).As described above, these transactions are only added to the ledger 1126after the transactions have been validated by the blockchain systemusing consensus-based validation techniques.

Since each industrial device within the blockchain system maintains alocal copy of this ledger 1126 of validated transaction data, programexecution component 1306 can be configured to leverage selected items ofthis ledger data in connection with controlling the system or process1320. For example, control program 1204 can be written to reference oneor more items of transaction data stored in the ledger 1126, such thatthese items of transaction data serve as parameters or inputs into thecontrol program 1204 that at least partially control the states of oneor more control outputs 1314. In this way, the blockchain-enabledindustrial controller 1210 can control a system or process 1320 basednot only on monitored local inputs from the system (input signals 1312),but also on events that occur at other production areas or machineswithin the plant.

This ledger-based control is not limited to the use of plant-levelevents to effect control of control outputs 1314. For example, if theledger 1126 records business-level transactions (e.g., work orderinformation, inventory information, etc.), program execution component1306 can leverage this information as parameters or inputs into controlprogram 1204. The ledger 1126 may also record validated events thatoriginate at other supply chain entities within the larger blockchainecosystem (e.g., part or sub-assembly suppliers, OEMs, retailers,shipping companies, etc.), and control program 1204 an be written toreference these external supply chain events as control parameters aswell.

Participants in an industrial blockchain ecosystem can access blockchaininformation to which they have authorized access in a variety of ways.FIG. 21 is a diagram illustrating an example, high-level architecturefor accessing blockchain information for a manufactured product using amobile user interface application 2110 installed on a mobile device2104. User interface application 2110 can be configured to interfacewith a publicly accessible blockchain search system 2106 maintained on apublic network or cloud platform 2106. In an example implementation,blockchain search system 2106 can comprise an interface component 2118and a blockchain search and management component 2122. These componentsof blockchain search system 2106 components can comprise, for example,machine-executable components embodied within one or more machines,e.g., embodied in one or more computer-readable mediums (or media)associated with one or more machines that are accessible via the cloudplatform or public network 2106. These components can be stored on oneor more memories and executed by one or more processors (not shown inFIG. 21) that make up part of blockchain search system 2106.

Blockchain search system 2106 can control remote access to versions ofindustrial blockchains 1304 a, 1304 b generated by industrial devices1102 throughout a supply chain or other industrial blockchain ecosystem.In the illustrated example, user interface application 2110 allows auser to access subsets of relevant blockchain data associated with afinished product 2108 by scanning a scannable code, such as a QR code,imprinted on the product 2108 using the mobile device's optical scanningcapabilities. The code establishes the identity of a source of theproduct's blockchain as well as the stored data to be accessed. When aproduct's code is scanned by the mobile device 2104 and an authenticuser identifier is provided to the user interface application 2110, theapplication 2110 sends the request 2114 together with the user identityinformation to the interface component 2118 of search system 2118.Interface component 2118 can verify the identity included in request2114 and determine a level of access associated with the identity. Inresponse to determining that the identity is an authorized user identityand that the identity is permitted a degree of access to at least asubset of available industrial blockchain information, interfacecomponent 2118 instructs blockchain search and management component 2122to search the blockchains 1304 a, 1304 b and retrieve a subset ofrelevant product data 2112 that the identified user is authorized toview based on the data request and identity. The interface component2118 renders the results on mobile device 2104. The user interfaceapplication 2110 can be configured to generate suitable graphicalscreens 2102 for rendering the authorized product data 2112. Search andmanagement component 2122 can be configured to retrieve the relevantblockchain data from any suitable source of the data accessible withinthe blockchain ecosystem, including but not limited to any of theblockchain-enabled industrial devices 1102 or other non-industrialsources of the requested data.

This approach can allow product consumers to access and view informationabout a purchased product via their personal devices. For example, if abatch of bottled water is found to be contaminated, scanning the labelon a bottle using a mobile device 2104 can cause user interfaceapplication 2110 to interact with search system 2116 to locate andretrieve information identifying a source of the water for thatparticular bottle. This water source information can be maintained in apublic blockchain accessible to consumers. Production details for thebottle itself (e.g., quality check results, cap tightening data, etc.)can also be accessed in this manner Some of this production data mayonly be accessible to plant personnel or consumers of certain roles. Inthe case of produce, data regarding the source of the produce (e.g., thefarm) as well as the time that the produce was picked can be captured asa blockchain generated by the industrial equipment (includingblockchain-enabled industrial devices 1102) that processes and packagesthe produce, such that the data can be retrieved by search system 2116and presented on mobile device 2104 in response to scanning an opticalcode associated with the produce (e.g., a code on a tag affixed to theproduce or on a bag containing the produce). In the case ofpharmaceuticals, this approach can allow consumers to verify theauthenticity of their medications by retrieving blockchain informationthat tracks the medication's supply chain. This supply chain informationcan be captured in a public blockchain and made accessible to consumers.

In some embodiments, user interface application 2110 can combinescanning of a product's optical code with voice-based or text-basedsearch. In an example embodiment, after scanning the product's scannablecode, the user can enter or speak a request for a certain type of datarelating to the product into their mobile device 2104 (e.g., “Confirmthat this product is organic,” “where was this water bottled,” etc.). Inresponse, the user interface application 2110 translates the spokeninformation request into query information that can be combined with thescanned optical code information, submit this combined information tothe blockchain search system on the cloud platform or public network2106, and retrieve a relevant subset of product data that satisfies theuser's request and is permitted to be viewed by that particular user (inaccordance with the user's identity and/or role).

Blockchain search system 2116 can bundle and send blocks of industrialblockchains to customers upon request via the user interface application2110, which can include interactive search features that assist the userin easily locating desired information. For example, rather than walkingthe blockchain to find information of interest, the user interfaceapplication 2110 can allow users to drill down to blockchain informationthey wish to see. In an example use case, a user may a time range intouser interface application 2110 together with a request to view allproducts that were created within the specified time range of interest.In response to this information, blockchain search system 2116 canretrieve, from the relevant blockchains 1304 a, 1304 b, identifiers ofproducts that were created within the specified time range. Also,external indices with links for selectable dimensions of the product canbe built to allow desired information to be found more quickly.

Credit card purchases can also become transactions recorded in theblockchain for a product, allowing products to be traced to the end user(e.g., bottles with a cap that was produced as part of a specified batchcan be traced to the owners of the bottles). Including consumertransactions in the product's blockchain can also allow notifications tobe targeted to a specific subset of consumers known to have purchased aproduct (e.g., in the case of recall notifications for a particularbatch of the product). Such notifications can be delivered to relevantclient devices 2104 associated with known purchasers of a product byblockchain search system 2116 (e.g., by interface component 2118) inresponse to receiving a request to notify from an authorized vendor ofthe product. The request to notify can include, for example, anindication of the products for which a notification is to be delivered,a notification criterion that can be used to identify the subset of theproducts that are subject to the notification (e.g., a time range duringwhich newly manufactured products are known to have been contaminated, arange of product serial numbers, a supplier known to have provideddefective parts, etc.), and other relevant information that can be usedby the system 2116 to determine which product purchasers should receivea notification. Based on the information included in the request tonotify, the search and management component 2122 can map the subset ofproduct serial numbers identified by the notification criterion to theindividuals known to have purchased those identified products. Thismapping can be determined based on the transaction information stored inthe product's blockchain. Interface component 2118 can then deliversuitable notifications to the client devices 2104 associated with theidentified purchases.

Including end user transactions as part of the product's blockchain canalso allow the blockchain to be mined by sales entities for sales leads.In this way, sales people can readily determine what customers haveordered in the past, as well as identify who within a given companyshould be targeted for sales campaigns.

The configurability of the blockchain-enabled industrial devices 1102can allow manufacturers to choose the information that customers areallowed to access. Manufacturers or their associates (e.g., suppliers,OEMs, etc.) can also retroactively add to the set of data that may beaccessed by consumers. For example, if a supplier wishes to provide morespecific information regarding the source of their water after theproducts have shipped, the accessibility level of this additionalinformation can be changed from private to public, thereby retroactivelyrendering this information accessible to consumers.

Although FIG. 21 depicts a mobile device 2104 as the means by whichindustrial blockchain data is accessed, other means for retrieving andviewing the information are also within the scope of one or moreembodiments. For example, HMI terminals and software can be configuredto support blockchain interfaces that retrieve and visualize selectedsubsets of blockchain information relevant to a particular productionarea or plant facility within which the HMI terminal is installed. Inanother example implementation, HMI terminals can be configured tointerface with blockchain search system 2116 over the public network2106 in a manner similar to client device 2104, allowing operators toretrieve supply-chain level blockchain information from the HMIterminal.

Blockchain search system 2116 can also be used to execute actionsassociated with smart contracts in some embodiments. For example, if asmart contract is between an OEM and a manufacturing entity of theblockchain ecosystem includes a provision for the OEM to replace machinecomponents or devices after a defined number of production cycles (orbased on another time-based or event-based criterion, such as totalenergy consumption, part count, downtime or alarm frequency, a KPIsetpoint, etc.), search system 2116 can monitor relevant subsets of datalogged in blockchains 1304 a or 1304 b to determine when the trigger forreplacing the component has been satisfied. This monitoring can beperformed by self-initiated searches performed by blockchain search andmanagement component 2122 on a periodic or continuous basis based oninstructions contained in the smart contract. In response todetermining, based on the monitoring, that the replacement conditiondefined by the smart contract has been satisfied, interface component2118 can generate and deliver a notification to personnel associatedwith the OEM entity that the component must be replaced at themanufacturing entity per the smart contract. In variations of suchembodiments, search system 2116 may also initiate other proceduresassociated with replacement of the part when the replacement trigger hasbeen satisfied, including generating a purchase order, submitting theorder to a vendor, scheduling an on-site visit by the OEM to replace thecomponent, etc. In general, blockchain search system 2116 can beconfigured to enforce or execute provisions of a smart contract betweenentities of an industrial blockchain ecosystem by monitoring forconditions defined by the smart contract or for deviations from agreedprovisions of the smart contract, and by executing appropriatenotification, reporting, or control actions in line with the smartcontract.

FIGS. 22-23 illustrate various methodologies in accordance with one ormore embodiments of the subject application. While, for purposes ofsimplicity of explanation, the one or more methodologies shown hereinare shown and described as a series of acts, it is to be understood andappreciated that the subject innovation is not limited by the order ofacts, as some acts may, in accordance therewith, occur in a differentorder and/or concurrently with other acts from that shown and describedherein. For example, those skilled in the art will understand andappreciate that a methodology could alternatively be represented as aseries of interrelated states or events, such as in a state diagram.Moreover, not all illustrated acts may be required to implement amethodology in accordance with the innovation. Furthermore, interactiondiagram(s) may represent methodologies, or methods, in accordance withthe subject disclosure when disparate entities enact disparate portionsof the methodologies. Further yet, two or more of the disclosed examplemethods can be implemented in combination with each other, to accomplishone or more features or advantages described herein.

FIG. 22 illustrates an example methodology 2200 for aggregatingindustrial blockchains in connection with manufacture of a compositeproduct. At 2202, an industrial control program is executed thatfacilitates monitoring and control of an industrial process thatassembles multiple components into a composite product. The industrialprocess can include, for example, a bottling process that fills, labels,and caps a bottle of beverage, an automotive manufacturing process thatassembles a vehicle or a sub-assembly thereof, a process thatmanufactures computer chips or electronic devices, a batch process, amining operation, or other such industrial processes. The controlprogram can be executed by an industrial controller having integratedblockchain capabilities.

At 2204, control events associated with control of the industrialprocess are bundled into blocks of an industrial blockchain associatedwith the product. In an example implementation, the control program mayinclude industrial blockchain instructions that are configured to bundlethe control events as validated transactions and record the transactionsinto one or more blocks of the industrial blockchain.

At 2206, a determination is made as to whether another blockchainassociated with one of the multiple components that are assembled intothe composite product has been received. The received blockchain maycomprises manufacturing transactions associated with the correspondingcomponent, which were recorded during production of the component byanother production area or outside supplier facility. If such ablockchain is not received (NO at step 2206), steps 2202-2204 arerepeated until a blockchain associated with one of the components isreceived.

If a blockchain associated with one of the multiple components received(YES at step 2206), the methodology proceeds to step 2208, where anauthenticity of the received blockchain is verified. Verification of thereceived blockchain can be based on a consensus technique (e.g.,proof-of-work, proof-of-state, practical byzantine fault tolerance,etc.) in which a consortium of devices within an industrial blockchainsystem, including the industrial controller and other industrial devicesand/or non-industrial devices), collectively verify the receivedblockchain's authenticity. At 2210, a determination is made as towhether the result of step 2208 determines that the received blockchainis authentic. If the received blockchain is not authentic (NO at step2210), the methodology returns to step 2202 and the received blockchainis not aggregated with the blockchain associated with the compositeproduct. Alternatively, if the received blockchain is determined to beauthentic (YES at step 2210), the received blockchain is aggregated intothe blockchain associated with the composite product at step 2212.

FIG. 23 illustrates an example methodology 2300 for generatingindustrial blockchains having multiple levels of access permission.Initially, at 2302, an industrial control program is executed thatfacilitates monitoring and control of an industrial process thatfacilitates manufacture of a product. At 2304, a determination is madeas to whether a first blockchain instruction of the industrial controlprogram is executed. If the first blockchain instruction is executed(YES at step 2304), the methodology proceeds to step 2306, where a firstset of control events associated with control of the industrial processis bundled into blocks of a first industrial blockchain associated withthe product in accordance with the first blockchain instruction. Perconfiguration parameters of the first blockchain instruction, the firstindustrial blockchain have a first level of access permission defined bythe first blockchain instruction. For example, the first industrialblockchain may be designated to be a fully public blockchain comprisingdata that can be accessed and viewed by all participants of theblockchain ecosystem (e.g., a product supply and distribution chain), ormay be a private blockchain accessible only to authorized users withinthe industrial facility within which the industrial process is beingcarried out. The first industrial blockchain may be configured to besemi-public, such that the blockchain data can be viewed only by one ormore selected outside entities within the blockchain ecosystem (e.g., anOEM, a supplier, or a customer entity). If the first blockchaininstruction is not executed (NO at step 2304), the methodology proceedsto step 2308 without executing step 2306.

At 2308, a determination is made as to whether a second blockchaininstruction of the industrial control program is executed. If the secondblockchain instruction is executed (YES at step 2308), the methodologyproceeds to step 2310, where a second set of control events associatedwith control of the industrial process is bundled into blocks of asecond industrial blockchain associated with the product in accordancewith the second blockchain instruction. Per the second blockchaininstruction, the second industrial blockchain can have a second level ofaccess permission that is different than the first industrial blockchaingenerated at step 2306.

Embodiments, systems, and components described herein, as well asindustrial control systems and industrial automation environments inwhich various aspects set forth in the subject specification can becarried out, can include computer or network components such as servers,clients, programmable logic controllers (PLCs), automation controllers,communications modules, mobile computers, wireless components, controlcomponents and so forth which are capable of interacting across anetwork. Computers and servers include one or more processors—electronicintegrated circuits that perform logic operations employing electricsignals—configured to execute instructions stored in media such asrandom access memory (RAM), read only memory (ROM), a hard drives, aswell as removable memory devices, which can include memory sticks,memory cards, flash drives, external hard drives, and so on.

Similarly, the term PLC or automation controller as used herein caninclude functionality that can be shared across multiple components,systems, and/or networks. As an example, one or more PLCs or automationcontrollers can communicate and cooperate with various network devicesacross the network. This can include substantially any type of control,communications module, computer, Input/Output (I/O) device, sensor,actuator, instrumentation, and human machine interface (HMI) thatcommunicate via the network, which includes control, automation, and/orpublic networks. The PLC or automation controller can also communicateto and control various other devices such as standard or safety-ratedI/O modules including analog, digital, programmed/intelligent I/Omodules, other programmable controllers, communications modules,sensors, actuators, output devices, and the like.

The network can include public networks such as the internet, intranets,and automation networks such as control and information protocol (CIP)networks including DeviceNet, ControlNet, and Ethernet/IP. Othernetworks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus,Profibus, CAN, wireless networks, serial protocols, near fieldcommunication (NFC), Bluetooth, and so forth. In addition, the networkdevices can include various possibilities (hardware and/or softwarecomponents). These include components such as switches with virtuallocal area network (VLAN) capability, LANs, WANs, proxies, gateways,routers, firewalls, virtual private network (VPN) devices, servers,clients, computers, configuration tools, monitoring tools, and/or otherdevices.

In order to provide a context for the various aspects of the disclosedsubject matter, FIGS. 24 and 25 as well as the following discussion areintended to provide a brief, general description of a suitableenvironment in which the various aspects of the disclosed subject mattermay be implemented.

With reference to FIG. 24, an example environment 2410 for implementingvarious aspects of the aforementioned subject matter includes a computer2412 (where computer 2412 may be an industrial controller or other typeof industrial device, a server device, or another type of computingdevice). The computer 2412 includes a processing unit 2414, a systemmemory 2416, and a system bus 2418. The system bus 2418 couples systemcomponents including, but not limited to, the system memory 2416 to theprocessing unit 2414. The processing unit 2414 can be any of variousavailable processors. Multi-core microprocessors and othermultiprocessor architectures also can be employed as the processing unit2414.

The system bus 2418 can be any of several types of bus structure(s)including the memory bus or memory controller, a peripheral bus orexternal bus, and/or a local bus using any variety of available busarchitectures including, but not limited to, 8-bit bus, IndustrialStandard Architecture (ISA), Micro-Channel Architecture (MSA), ExtendedISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB),Peripheral Component Interconnect (PCI), Universal Serial Bus (USB),Advanced Graphics Port (AGP), Personal Computer Memory CardInternational Association bus (PCMCIA), and Small Computer SystemsInterface (SCSI).

The system memory 2416 includes volatile memory 2420 and nonvolatilememory 2422. The basic input/output system (BIOS), containing the basicroutines to transfer information between elements within the computer2412, such as during start-up, is stored in nonvolatile memory 2422. Byway of illustration, and not limitation, nonvolatile memory 2422 caninclude read only memory (ROM), programmable ROM (PROM), electricallyprogrammable ROM (EPROM), electrically erasable PROM (EEPROM), or flashmemory. Volatile memory 2420 includes random access memory (RAM), whichacts as external cache memory. By way of illustration and notlimitation, RAM is available in many forms such as synchronous RAM(SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rateSDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), anddirect Rambus RAM (DRRAM).

Computer 2412 also includes removable/non-removable,volatile/non-volatile computer storage media. FIG. 24 illustrates, forexample a disk storage 2424. Disk storage 2424 includes, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, Jaz drive, Zip drive, LS-100 drive, flash memory card, or memorystick. In addition, disk storage 2424 can include storage mediaseparately or in combination with other storage media including, but notlimited to, an optical disk drive such as a compact disk ROM device(CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive (CD-RWDrive) or a digital versatile disk ROM drive (DVD-ROM). To facilitateconnection of the disk storage 2424 to the system bus 2418, a removableor non-removable interface is typically used such as interface 2426.

It is to be appreciated that FIG. 24 describes software that acts as anintermediary between users and the basic computer resources described insuitable operating environment 2410. Such software includes an operatingsystem 2428. Operating system 2428, which can be stored on disk storage2424, acts to control and allocate resources of the computer 2412.System applications 2430 take advantage of the management of resourcesby operating system 2428 through program modules 2432 and program data2434 stored either in system memory 2416 or on disk storage 2424. It isto be appreciated that one or more embodiments of the subject disclosurecan be implemented with various operating systems or combinations ofoperating systems.

A user enters commands or information into the computer 2412 throughinput device(s) 2436. Input devices 2436 include, but are not limitedto, a pointing device such as a mouse, trackball, stylus, touch pad,keyboard, microphone, joystick, game pad, satellite dish, scanner, TVtuner card, digital camera, digital video camera, web camera, and thelike. These and other input devices connect to the processing unit 2414through the system bus 2418 via interface port(s) 2438. Interfaceport(s) 2438 include, for example, a serial port, a parallel port, agame port, and a universal serial bus (USB). Output device(s) 2440 usesome of the same type of ports as input device(s) 2436. Thus, forexample, a USB port may be used to provide input to computer 2412, andto output information from computer 2412 to an output device 2440.Output adapters 2442 are provided to illustrate that there are someoutput devices 2440 like monitors, speakers, and printers, among otheroutput devices 2440, which require special adapters. The output adapters2442 include, by way of illustration and not limitation, video and soundcards that provide a means of connection between the output device 2440and the system bus 2418. It should be noted that other devices and/orsystems of devices provide both input and output capabilities such asremote computer(s) 2444.

Computer 2412 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)2444. The remote computer(s) 2444 can be a personal computer, a server,a router, a network PC, a workstation, a microprocessor based appliance,a peer device or other common network node and the like, and typicallyincludes many or all of the elements described relative to computer2412. For purposes of brevity, only a memory storage device 2446 isillustrated with remote computer(s) 2444. Remote computer(s) 2444 islogically connected to computer 2412 through a network interface 2448and then physically connected via communication connection 2450. Networkinterface 2448 encompasses communication networks such as local-areanetworks (LAN) and wide-area networks (WAN). LAN technologies includeFiber Distributed Data Interface (FDDI), Copper Distributed DataInterface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and thelike. WAN technologies include, but are not limited to, point-to-pointlinks, circuit switching networks like Integrated Services DigitalNetworks (ISDN) and variations thereon, packet switching networks, andDigital Subscriber Lines (DSL). Network interface 2448 can alsoencompass near field communication (NFC) or Bluetooth communication.

Communication connection(s) 2450 refers to the hardware/softwareemployed to connect the network interface 2448 to the system bus 2418.While communication connection 2450 is shown for illustrative clarityinside computer 2412, it can also be external to computer 2412. Thehardware/software necessary for connection to the network interface 2448includes, for exemplary purposes only, internal and externaltechnologies such as, modems including regular telephone grade modems,cable modems and DSL modems, ISDN adapters, and Ethernet cards.

FIG. 25 is a schematic block diagram of a sample computing environment2500 with which the disclosed subject matter can interact. The samplecomputing environment 2500 includes one or more client(s) 2502. Theclient(s) 2502 can be hardware and/or software (e.g., threads,processes, computing devices). The sample computing environment 2500also includes one or more server(s) 2504. The server(s) 2504 can also behardware and/or software (e.g., threads, processes, computing devices).The servers 2504 can house threads to perform transformations byemploying one or more embodiments as described herein, for example. Onepossible communication between a client 2502 and servers 2504 can be inthe form of a data packet adapted to be transmitted between two or morecomputer processes. The sample computing environment 2500 includes acommunication framework 2506 that can be employed to facilitatecommunications between the client(s) 2502 and the server(s) 2504. Theclient(s) 2502 are operably connected to one or more client datastore(s) 2508 that can be employed to store information local to theclient(s) 2502. Similarly, the server(s) 2504 are operably connected toone or more server data store(s) 2510 that can be employed to storeinformation local to the servers 2504.

What has been described above includes examples of the subjectinnovation. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe disclosed subject matter, but one of ordinary skill in the art mayrecognize that many further combinations and permutations of the subjectinnovation are possible. Accordingly, the disclosed subject matter isintended to embrace all such alterations, modifications, and variationsthat fall within the spirit and scope of the appended claims.

In particular and in regard to the various functions performed by theabove described components, devices, circuits, systems and the like, theterms (including a reference to a “means”) used to describe suchcomponents are intended to correspond, unless otherwise indicated, toany component which performs the specified function of the describedcomponent (e.g., a functional equivalent), even though not structurallyequivalent to the disclosed structure, which performs the function inthe herein illustrated exemplary aspects of the disclosed subjectmatter. In this regard, it will also be recognized that the disclosedsubject matter includes a system as well as a computer-readable mediumhaving computer-executable instructions for performing the acts and/orevents of the various methods of the disclosed subject matter.

In addition, while a particular feature of the disclosed subject mattermay have been disclosed with respect to only one of severalimplementations, such feature may be combined with one or more otherfeatures of the other implementations as may be desired and advantageousfor any given or particular application. Furthermore, to the extent thatthe terms “includes,” and “including” and variants thereof are used ineither the detailed description or the claims, these terms are intendedto be inclusive in a manner similar to the term “comprising.”

In this application, the word “exemplary” is used to mean serving as anexample, instance, or illustration. Any aspect or design describedherein as “exemplary” is not necessarily to be construed as preferred oradvantageous over other aspects or designs. Rather, use of the wordexemplary is intended to present concepts in a concrete fashion.

Various aspects or features described herein may be implemented as amethod, apparatus, or article of manufacture using standard programmingand/or engineering techniques. The term “article of manufacture” as usedherein is intended to encompass a computer program accessible from anycomputer-readable device, carrier, or media. For example, computerreadable media can include but are not limited to magnetic storagedevices (e.g., hard disk, floppy disk, magnetic strips . . . ), opticaldisks [e.g., compact disk (CD), digital versatile disk (DVD) . . . ],smart cards, and flash memory devices (e.g., card, stick, key drive . .. ).

What is claimed is:
 1. An industrial device, comprising: a processor,operatively coupled to a memory, that executes executable componentsstored on the memory, the executable components comprising: an executionengine configured to execute an industrial control program thatfacilitates monitoring and control of an industrial process managed by amanufacturing entity; a blockchain engine configured to: receive, from arecipe provider, an industrial blockchain comprising recipe data thatdefines at least one of parameters or executable instructions usable bythe industrial control program to control the industrial process tofacilitate manufacture a specified product; verify an authenticity ofthe recipe data; verify that the industrial device is authorized toexecute the recipe data; and contingent on verification of theauthenticity of the recipe data and verification that the industrialdevice is authorized to execute the recipe data, permit the executionengine to execute the industrial control program using the recipe data.2. The industrial device of claim 1, wherein the recipe data is embeddedin the industrial blockchain as encrypted recipe data, and theblockchain engine is further configured to decrypt the recipe data usinga private key associate with the industrial device.
 3. The industrialdevice of claim 1, wherein the industrial blockchain further comprisescontract data that defines an expiration criterion that limits an amountof the product to be manufactured by the manufacturing entity, and theblockchain engine is further configured to prevent execution of therecipe data by the execution engine in response to a determination thatthe expiration criterion has been satisfied.
 4. The industrial device ofclaim 3, wherein the expiration criterion is at least one of a specifiednumber of units of the product to be manufactured by the manufacturingentity, an expiratory date, or consumption of a specified amount ofpower by the industrial process while manufacturing the product.
 5. Theindustrial device of claim 1, wherein the recipe provider is an originalequipment manufacturer, and the industrial control program facilitatesmonitoring and control of a machine built by the original equipmentmanufacturer for manufacture of the product.
 6. The industrial device ofclaim 1, wherein the blockchain engine is further configured to generateorders for ingredients identified by the recipe data that are obfuscatedto the manufacturing entity.
 7. The industrial device of claim 1,wherein the recipe data further defines a location at which the recipedata is permitted to execute, and the blockchain engine is furtherconfigured to permit the execution engine to execute the industrialcontrol program using the recipe data contingent on a determination thatthe industrial device is at the location.
 8. The industrial device ofclaim 1, wherein the blockchain engine is further configured to record,in the industrial blockchain, a public ledger of production statisticsassociated with the manufacture of the specified product using therecipe data, and the public ledger is accessible to the manufacturingentity and the recipe provider.
 9. The industrial device of claim 8,wherein the production statistics comprise at least one of a number ofunits of the product that have been produced using the recipe data or anelapsed runtime of the industrial control program using the recipe data.10. The industrial device of claim 8, wherein the blockchain engine isfurther configured to record, in the industrial blockchain, a privateledger of recipe statistics associated with execution of the recipedata, and the private ledger is accessible to the manufacturing entityand is inaccessible to the recipe provider.
 11. The industrial device ofclaim 10, wherein the recipe statistics comprise at least one ofidentities of plant personnel who operated a machine associated with theindustrial process, runtime statistics for the machine, downtimestatistics for the machine, product defect statistics, or numbers ofbatches of different recipes executed by the industrial control program.12. A method, comprising: receiving, by an industrial controllercomprising a processor, an industrial blockchain that encodes recipedata from a recipe provider, the recipe data defining at least one ofparameters or executable instructions usable by an industrial controlprogram to control an industrial process managed by a manufacturingentity to facilitate manufacture a specified product; verifying, by theindustrial controller, an authenticity of the recipe data; verifying, bythe industrial controller, that the industrial controller is authorizedto execute the recipe data; and in response to the verifying of theauthenticity and the verifying that the industrial controller isauthorized to execute the recipe data, executing, by the industrialcontroller, the industrial control program using the recipe data. 13.The method of claim 12, wherein the recipe data is embedded in theindustrial blockchain as encrypted recipe data, and the method furthercomprises: decrypting, by the industrial controller, the recipe datausing a private key associate with the industrial controller.
 14. Themethod of claim 12, wherein the industrial blockchain further comprisescontract data that defines an expiration criterion that limits an amountof the product to be manufactured by the manufacturing entity, and themethod further comprises preventing, by the industrial controller,execution of the recipe data in response to determining that theexpiration criterion has been satisfied.
 15. The method of claim 14,wherein the expiration criterion is at least one of a specified numberof units of the product to be manufactured by the manufacturing entity,an expiratory date, or consumption of a specified amount of power by theindustrial process while manufacturing the product.
 16. The method ofclaim 12, wherein the recipe data further defines a location at whichthe recipe data is permitted to execute, and the method furthercomprises executing, by the industrial controller, the industrialcontrol program using the recipe data contingent on a determination thatthe industrial device is at the location.
 17. The method of claim 12,further comprising: recording, by the industrial controller in theindustrial blockchain, a public ledger of production statisticsassociated with the manufacture of the specified product using therecipe data, wherein the public ledger is accessible to themanufacturing entity and the recipe provider.
 18. The method of claim17, further comprising: recording, by the industrial controller in theindustrial blockchain, a private ledger of recipe statistics associatedwith execution of the recipe data, wherein the private ledger isaccessible to the manufacturing entity and is inaccessible to the recipeprovider.
 19. A non-transitory computer-readable medium having storedthereon instructions that, in response to execution, cause an industrialdevice comprising a processor to perform operations, the operationscomprising: receiving an industrial blockchain that encodes recipe datafrom a recipe provider, wherein the recipe data defines at least one ofparameters or executable instructions usable by an industrial controlprogram to control an industrial process managed by a manufacturingentity to facilitate manufacture a specified product; verifying that therecipe data is digitally signed by the recipe provider; verifying thatthe industrial device is authorized to execute the recipe data; and inresponse to the verifying that the recipe data is digitally signed andthe verifying that the industrial device is authorized to execute therecipe data, executing the industrial control program using the recipedata.
 20. The non-transitory computer-readable medium of claim 19,wherein the industrial blockchain further comprises contract data thatdefines an expiration criterion that limits an amount of the product tobe manufactured by the manufacturing entity, and the operations furthercomprise preventing execution of the recipe data on the industrialdevice in response to determining that the expiration criterion has beensatisfied.